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If you read the PC magazines, you no doubt have noticed that the new rage in software is the 
Personal Information Manager. Products in this new category of software store various 
information in a database that can be easily recalled through categories or keywords. We set out 
to create a similar program for you. Although it is impossible to match one of the PC programs 
in the couple hundred lines of code we allow in the magazine, we have come up with a program 
that can be a great help to you in organizing diverse bits of information. 

The program we have named INFO organizes your information by having you assign a major 
category, a minor category, and a heading to each "window" of information you enter. This 
structure allows an alphabetic hierarchical display of what is contained in each window. From 
this display you can very quickly find the information you are looking for, and bring it up on the 
screen in seconds. 

There are many specific applications for INFO, but it is best at being your TOTAL information 
manager. You can store information about all your suppliers, your equipment, maintenance 
contracts, projects, personal data, etc. No matter how many different types of data you include, 
INFO organizes it all in an easy access format. 

To use INFO, just call CL program INFO. This will bring up the scan screen. The first time you 
use INFO, it will be blank, of course. To enter some information, press function key 2. The enter 
screen will be displayed. Key a major category, a minor category, a heading, and up to 17 lines 
of data. For example, you could enter AS/400 as the major category, MAINTENANCE as the 
minor category, XL DATACOMP as the heading, and related information in the lines below. 
After pressing enter, the record is added and you are again presented with a blank entry screen. 
Enter as many records as you want, and then press function key 12 to return to the scan screen. 

From the scan screen you can use the roll keys to roll forward and backward through the file. 
When you wish to access the detail of one of the records, key the number that is to the right of 
the heading and press enter. This will display the information in the same format in which you 
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entered it. If no changes are made, you can press function key 12 to return to the scan screen. Or, 
you can make changes to any field and then press enter to update the record and return to the 
scan screen. The only restriction in what you key is that you cannot create two records with the 
same Category and heading fields. If you attempt to, the screen will be re-displayed. Pressing 
function key 24 will delete the record. 

Function key 3 will end the job. 

Enhancements You Can Make 

Since we try to keep the programs that we publish short, there are always enhancements you can 
add to make the program better. You can really make the program more powerful by allowing 
more than one screen of information for each record. This can most efficiently be accomplished 
by breaking up the INFOFILE into two files. One would contain the categories and heading. The 
other would contain one record for each line of screen data. The two files would have to be tied 
together with some kind of linking field. You could then add roll keys to let the user page 
through an unlimited number of screens. 

And, as in any of the programs that we publish, you should add more editing of the input fields. 

Figure 1 RPG program for Information Manager 
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Figure 2 CL program for Information Manager 

INFO: + 

PGM 

CHKOBJ OBJ(*CURLIB/INFOPFl) OBJTYPE(*FILE) 

MONMSG MSGID(CPF9801) EXEC(CRTPF FILE(INFOPF1) + 

SRCFILE(*CURLIB/QDDSSRC) SRCMBR(INFOPF1) OPTION(*NOSRC *NOLIST)) 

CALL PGM(*CURLIB/INFOR1) 

ENDPGM 


Figure 3 Display file for Information Manager 
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Figure 4 Physical file for Information Manager 
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If you are getting an AS/400 this early in its product life, you had better prepare yourself to 
periodically spend some time working with PTF's (Program Temporary Fixes). Because of the 
magnitude of the software and IBM's rush to get it out the door, you can expect to find PTF's 
coming out faster than you can keep track of them. 

In all fairness, IBM has been quick to make corrections and is providing support reminiscent of 
the old IBM days. With the effort IBM is expending on the AS/400 product line, any problems 
that come up should be quickly resolved. But the fact is, that at the present time, awareness and 
management of PTF's is a requirement for every AS/400 site. 

You'll find that the world of AS/400 PTF's is not the same as the world of S/36 PTF's. Not only 
is PTF application different, but it takes more time and effort than it does on the S/36. 

When you are combining a new machine, new PTF procedures, a lengthier process, and 
Electronic Customer Support, you have a definite need for some helpful guidance. That is the 
purpose of this article. 

Electronic Customer Support 

IBM has provided each AS/400 with Electronic Customer Support (ECS), a modem, and a toll- 
free number so that you can have the computer call IBM directly 24 hours a day, 7 days a week 
to download PTF's or listings containing general and detailed information about currently 
available PTF's. The ECS feature can greatly improve the turn-around time required to receive 
PTF's. 

Before you can use the ECS service you will have to prepare your AS/400. Refer to the 
Electronic Customer Support User's Guide. You should have received this manual with your 
welcome packet shortly after receiving your system. 

Preventive Packages or Individual PTF's 
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You can order either the most recent preventive PTF package, which contains all the individual 
PTF's that have been created since the latest release/modification level, or individual PTF's with 
each one fixing a particular problem. 

If you are not having any problems with your software, ordering the preventive packages on a 
quarterly basis should be sufficient. 

Finding Out What PTF's To Download 

There are two lists available through ECS that should give you all the information you need to 
determine what PTF's you may need. These are the Preventive Service Planning Information 
(PSP) report, and the PTF Summary list. 

The PSP report provides you with information about major problems with a particular release of 
IBM licensed software. It contains a lot of information that can help you determine if you need to 
apply PTF's. For example, under the Service Recommendation section, problems are listed, users 
affected and recommendations are given. The report is made up of two major sections, 
UPGRADE 5728rvl, and UPGRADE 40PREVENTrvl (where r = release, v = version, 1 = 
modification level). 

The UPGRADE 5728rvl section is divided into subsets containing information about problems 
with licensed software. 

The UPGRADE 40PREVENTrvl section contains a list of the preventive PTF packages that 
have been created up to this time for a particular version, release, modification level. Each 
package ID is listed, starting from the oldest and ending with the most current. 

Each of the two sections mentioned above is broken down into the following categories: 

Change Summary 

Installation Information 

Documentation Changes 

General Information 

Service Recommendations 

Cross Product Dependencies 

The PTF Summary list contains every PTF created for a release up to the date the list was 
requested. The list gives you the PTF number, the preventive package ID it can be found in (if it 
has been placed in one yet), a brief description of the PTF, and if it has been replaced by a later 
PTF. If, after applying the preventive package, you find that a problem still persists, you could 
search through the PTF's that have not been placed into a preventive package yet ('NONE' under 
PKG# heading), to see if there is one that will fix your problem.By looking at this summary list 
and comparing it to the PTF's on your system (use the DSPPTF command), you can easily 
determine what PTF's are not on your system. You can also find the latest preventive PTF 
package at the top of the PTF Summary list beginning with Release 1.2. 
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Chapter 6 of the Operator's Guide explains how you can use ECS to get the PTF information just 
described. We'll summarize the steps for you here. 

To begin with, enter GO CMDPTF to get to the PTF menu, and then select option 6. You can 
bypass the menu by keying SNDPTFORD and pressing F4. 

You will be prompted for a specific PTF identifier. Although this is used to order actual PTF's, it 
is also set up to order PTF listings. To get either of the lists, you need to enter a special PTF 
number as follows: 

SFnnrvm where: 

if nn = 97, PTF summary list if nn = 98, PSP information r = Release v = Version m = 
Modification 

For example, if you want a PTF summary list for Version 1, Release 1, Modification 0, enter 
SF97110. 

After entering the PTF number, a screen will appear with your support contact information 
(Name, Address, Phone) you entered when you set up your ECS system. This screen allows you 
to make any changes to the information before the PTF request is sent. 

After pressing enter from the support contact information screen, a screen will be displayed with 
three options: 

1. Send service request 2. Do not send service request 3. Report service request by voice 

Select option 1. The system will then proceed to sign-on the service support system. 

If you are unable to connect to the remote system, a message will appear, "Cannot connect to 
remote support system". You will also receive a message in the QSYSOPR message queue 
giving you information about why the connection failed. 

When unable to connect with ECS you may try your alternate phone number for the IBM service 
system. To invoke the alternate number, key CAFF QESTEFE2. If you want to restore the 
primary number, key CAFF QESTEFE1. 

Ordering PTF's 

Before ordering a preventive PTF package or an individual PTF, you should review the PSP 
report and the PTF summary listing. 

You should use ECS to order your PTF's and take advantage of being able to immediately 
download them to your AS/400. If a PTF is too large to be transmitted over the ECS service line, 
a message will be displayed at the time of the request informing you that the PTF will be sent by 
mail. All preventive packages are sent by mail. If you are having trouble with ECS you can still 
order the PTF's through Fevel I. 

Ordering PTF's through ECS is identical to the steps described for ordering the PTF lists, with 
the exception of the PTF identifier. 
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To order a specific PTF, just enter the number of the PTF in the SNDPTFORD parameter. If you 
want to order a preventive package, key SF99vrm 

For example, if you want the latest preventive package for 1.2, key SF99112. 

When PTF's are copied from ECS, a cover letter is automatically sent to the QPRINT output 
queue in QGPL library, where you can either display it or print it. It will show you the applicable 
licensed program code, pre-requisite and/or co-requisite PTF's (if any), what PTF's may be 
superseded, a description of the problem fixed, the correction, circumvention, special 
instructions, and whether the PTF must be applied from a command screen or at IPL time 
(delayed PTF). After the PTF letter is received, the actual PTF is transmitted. Unfortunately, 
there is no information presented that gives you the amount of time the PTF will take to 
download to your system. We had several that took more than 30 minutes. This may be 
frustrating to someone who is trying to schedule their time while requesting PTF's. 

When individual PTF's are received through the mail on tape, you will receive a document 
describing the tape. Included in this description is a tape label and sequence number for the cover 
letter for each PTF on the tape. To print the cover letter, key CPYFRMTAP and press F4. Submit 
the following parameters: 

Tape file: QTAPE Library: QGPL To file: *PRINT Sequence number: (Found on tape 
description document) Tape Label: (Found on tape description document) Device: (Your tape 
device name) 

It appears that it is possible that PTF's could be sent on diskette, although we don't know under 
what circumstances this would happen. If it does, the procedure for printing the cover letter 
should be similar. 

How to Install PTF's 

The first step in installing PTF's is to load them on to your system. Whether you have received 
your PTF's through the ECS line, by tape, or by diskette, the PTF's are loaded with the LODPTF 
command. This command prompts you for the device (your tape or diskette device name for a 
tape or diskette, or *SERVICE for PTF's received through ECS). 

Once you have the PTF's loaded, you will need to apply them. At this point you must make sure 
you have a dedicated system. 

There are two types of PTF's that you may be installing. A PTF that begins with the characters 
MF is a microcode PTF. A PTF beginning with any other characters means it is a program PTF. 
These two types of PTF's are applied differently. We will first discuss program PTF's. 

Program PTF's can be applied temporarily or permanently. We suggest that you always apply 
new PTF's temporarily, since they can be removed if any problems are encountered. However, 
all temporary PTF's will have to be made permanent when you apply a new preventive package 
or an individual PTF which supersedes a temporary PTF on your system. 

The licensed program product code will be needed when you load and apply your program 
PTF's. The PTF summary list groups PTF's by licensed program product code, so you can easily 
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identify the product code to which a PTF belongs. 

There are two types of program PTF's, immediate and delayed. The immediate PTF's can be 
applied at any time, but the delayed can only be applied at an IPL. The listings and cover letters 
tell you which PTF's are immediate and which are delayed, but if you apply them the way we 
show you here you will not have to worry about what category they fall in. You will be running 
the APYPTF command (also found on the CMDPTF menu, option 1) twice for each licensed 
program product installed on your system for which you have PTF's once for immediate program 
PTF's and once for delayed program PTF's. To apply temporarily, specify *TEMP in the 'Extent 
of Change' parameter. To apply permanently, use *PERM. 

To apply the immediate program PTF's, run APYPTF with the DELAYED keyword as *NO. 
When this is finished, run APYPTF again with the DELAYED keyword as *YES and the 
IPLAPY keyword as *YES. This second step tells the computer to apply the delayed PTF's at the 
next unattended IPL. After this step, you will receive a message on your command screen, 
"Delayed PTFs identified for automatic apply or remove". After you have completed both steps 
for each program product that needed to have PTF's applied, perform an unattended IPL (see 
chapter 2 of the Operator's Guide). 

Applying microcode PTF's is a somewhat different procedure. The AS/400 can be IPL'd with 
either of two different copies of microcode. One copy contains all permanently applied PTF's 
(Copy A), and the other copy contains permanent and temporarily applied PTF's (COPY B). To 
determine which copy of microcode is being used, set the key to normal, select function 'OF and 
press the enter button. The left Data window will display what copy of the microcode the system 
is currently using. 

Temporarily applying microcode PTF's requires two IPL's. First, perform an IPL with an 'A' 
showing in the Data display of the control panel (if you don't know how to do this, refer to the 
Operator's Guide). Then use the APYPTF command as you would for program PTF's, only enter 
'5728999' in the licensed program parameter and *TEMP in the 'Extent of Change' parameter. 
When completed, the 'A' shown in the Data display will change to a 'B'. Then perform another 
IPL with 'B' showing in the Data display to complete the application. 

Applying microcode PTF's permanently requires one IPL. Perform an IPL with a 'B' showing in 
the Data display of the control panel. Then use the APYPTF command to permanently apply the 
PTF's, using '5728999' in the licensed program parameter and *PERM in the 'Extent of Change' 
parameter. At this point the PTF's are applied. You will receive a message on your command 
screen "Microcode PTFs have been applied or removed". 

Removing PTF's 

You can remove PTF's that have been applied temporarily, or loaded and not yet applied. They 
can be removed temporarily or permanently. If temporarily removed, they can be applied again. 
To remove PTF's, key RMVPTF and press F4, or key GO CMDPTF and select option 5. To 
remove delayed PTF's permanently, you must remove them temporarily, IPL, remove them 
permanently, and then IPL again. 

Permanently Applying Existing Temporary PTF's 
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When you receive a new preventive PTF package, or a PTF that supercedes a temporary PTF 
already applied, you will need to permanently apply your applicable temporary PTF's. Just use 
the APYPTF command as you did before but use *PERM in the 'Extent of Change' parameter. 

Deleting PTF Save Files 

After you have applied a PTF, you can use DFTF to delete any PTF save files that were created 
when the PTF's were copied to your system (by ECS, tape, or diskette). Unless otherwise 
specified, the files should be in the QGPF library. 

References: 

Operator's Guide SC21-8082-0 Electronic Customer Support User's Guide G360-1029-00 
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On the System/36, when you execute a procedure, the system searches the current library first, 
followed by #LIBRARY. On the AS/400, the libraries are also searched in a particular order only 
it is a more complex search. 

While the System/36 has a list, so to speak, of two libraries (the current library and #LIBRARY) 
to search, the AS/400 has a list of up to dozens of libraries it may search. This listing of library 
names is called a library list. The order of the search is dependent upon the order of the libraries 
in the list. 

Each job has its own library list, with base library names initially assigned according to system 
value definitions. From this starting point, library names can be added, removed, or repositioned 
in the list through an array of commands issued from either interactive or batch jobs. 

To see what your library list contains at any time, you can issue the command DSPLIBL 
(Display Library List). 

A library list is made up of four parts: 

System (SYS) Libraries: These are libraries that the system uses, such as QSYS and QHLPSYS. 
The system library names are defined for all jobs in the system value QSYSLIBL. 

Product (PRD) Libraries: These are the libraries that contain licensed program products that are 
installed on your system. You don't need to add the names of the product libraries to the list. The 
commands that access product library objects automatically designate the appropriate library 
name to the library list as the current library for the duration of the command job. 

Current (CUR) Library: One user library on your list can be considered the current library, which 
is searched before any other user libraries on the list. A current library is not required. 

User (USR) Libraries: These are the names of the libraries that contain user objects, such as files 
and programs. 
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The list is stored in the order we have presented the four types of library entries. When the 
library list is searched, it is searched in a top-to-bottom order until the object is located. Once the 
object is found, the search ends. This is very powerful in that you can access objects from several 
libraries without having to designate the library name each time. But it also presents the case for 
proper object naming and management. If you have two libraries on the list that contain objects 
of the same name, only the object from the highest level library will be accessed. Figure 1 shows 
an example of how a library list is searched. 

The IBM-Supplied Library List 

Various libraries are included in the default library list when the system is shipped from IBM. 

These libraries are listed here in the library list order: 

QSYS (System Library): Contains the OS/400 licensed programs, system commands, and other 
system objects shipped with the system. Also contains other objects such as device descriptions 
and authorization lists created by the user. Found in the system library portion. 

QHLPSYS (System Help Library): All the IBM-supplied help information. Found in the system 
library portion. 

QUSRSYS (User System Library): This library is where you can place your commands to be 
accessed from anywhere (assuming you have not removed QUSRSYS from the library list). 

Found in the system library portion. 

QTEMP (Temporary Library): A user library that contains temporary objects that are created for 
each job. Found in the user library portion. 

QGDDM (Graphics Data Display Manager Library): This library contains objects used by 
GDDM. Found in the user library portion. 

QGPL (General Purpose Library): Contains some IBM-supplied objects, as well as user-created 
objects that did not have a target library specified when they were created. Becomes the current 
library unless otherwise specified. Found in the user library portion. 

System/36 Execution Environment Additional Entries 

The System/36 execution environment automatically adds three other libraries to the top of the 
user portion of the library list. 

#LIBRARY (S/36 #LIBRARY User Member Library): Not the old System #LIBRARY as you 
know it. This library is created to contain user members that existed in #LIBRARY, plus the file 
QS36ENV which contains System/36 - AS/400 cross-references. 

If a current library is not already specified, #LIBRARY also becomes the current library. 

QSSP (S/36 System Library): This contains the IBM System/36 compatible programs. 

QS36F (S/36 File Library): This library contains all the data files pertaining to the System/36 
execution environment. 

Setting Up Your Own Defaults 
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The system value QSYSLIBL stores the default system libraries and the system value 
QUSRLIBL stores the default user libraries. When a job is initiated, it is the libraries that are 
specified in these values that are used to create the base library list for the job. In addition, if a 
user profile has a current library specified in its CURLIB parameter, that library is set up as a 
current library. In the native environment, if no current library is set up in the user profile, QGPL 
becomes the current library; in the System/36 environment, #LIBRARY becomes the current 
library. 

DSPSYSVAL QSYSLIBL and DSPSYSVAL QUSRLIBL will display the system values 
containing the system and user library list portions, respectively. To change the list defaults, use 
the CHGSYSVAL command with the same system value keywords and press F4 for assistance. 

To display and change a user profile's current library, key the command WRKUSRPRF and 
press F4 for assistance. 

Changing the Library List for a Job 

As we talk about changing the library list for a job, remember that the time from sign on to sign 
off is considered one interactive job. 

The CHGSYSLIBL (Change System Library List) command will change the system portion of 
the library list for the job in which the command is entered. Specifically, you can add a system 
library to the top of the list or remove a system library from the list. The library QSYS cannot be 
removed. CHGSYSLIBL can be used in either an interactive or batch job. The user running this 
command must be a security officer or a user with the *ALLOBJ special authority. 

The CHGLIBL (Change User Library List) command will perform two functions. For one, it 
changes the user libraries in the current job's list to the list of libraries specified by the user. It 
will also change the name of the current library. To run this command, the user must have object 
operational authority for all specified libraries. 

To change the user library list with CHGLIBL, you just specify up to 25 library names. These 
library names, in the order keyed, will replace the previous user libraries in the list. 

To change the current library with CHGLIBL, you just key the new library name in the proper 
parameter. 

The ADDLIBLE (Add Library List Entry) command will add a library name to the user portion 
of the library list. It can be added to the top of the user list (just before the current library) or at 
the end of the list. 

The RMVLIBLE (Remove Library List Entry) command will remove a library from the user 
portion of the list. 

In an interactive job, you can use the EDITLIBL command to easily change, add, remove, and 
reorder the libraries on your library list. Just key in EDTLIBL to get an easy to use screen that 
will allow the changes. 

If you specify a current library name on the sign-on display, that library is used as your current 
library until you sign off or change it. 
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Figure 1 An example of a library list display (DSPLIBL) 
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Multiple column listings come in handy in a variety of situations. By fitting more on a page, the 
report is easier to digest for a user, and offers a paper savings as well. There are two types of 
multiple column formats from which you can choose. One prints the data in the columns from 
left-to-right, top-to-bottom. The other prints from top-to-bottom, left-to-right. These two formats, 
which for the purposes of this article we will call the "Across" and "Down" formats, respectively, 
are illustrated in Figure 1. 

The Across Format 

Programming for the Across format is much simpler than for the Down format. Just set up one 
array that has the same number of elements as there are number of columns. Place the first data 
item in element 1, the second in element 2, etc. When the last element of the array is filled, print 
the line, clear the array, and then start the process over. When the last record is read, the line is 
printed if there is any data in it. 

Figure 2 illustrates partial code that will print a four column listing in the Across format. You'll 
need to add the file processing and overflow handling. 

The Down Format 

The Down format is a bit more complicated than the Across format, but is still a rather simple 
technique. The first thing you will need to do is determine the number of rows that will fit on a 
page. Multiply the number of rows by the number of columns that will be on the page. Then 
create an array with that many elements. As each record is read, place it in the next empty 
element. Once the entire array is filled, or the last record of data has been read, print the columns 
for all rows of the page. 

Figure 3 shows partial code that will print a four column by fifty row per page listing. You'll 
need to add the file processing and overflow handling. In this format, you will need to perform 
overflow output after output of the array to the page. 
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Figure 1 "Across" and "Down" formats 
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Figure 2 Sample code to print across columns 
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Figure 3 Sample code to print down columns 
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Since getting our AS/400 we have been annoyed by the many JOBLOG's that keep printing. 

Unless there is a problem, a job log does not need to be printed. For example, every time we did 
a compile that had terminal errors, we would get a job log. After a little studying we determined 
how we could save the JOBLOG's for future reference without printing them or cluttering up our 
output queue. Before we explain how we did it, it will help to give a little background on how 
the AS/400 handles printed output. 

On the System/36, spooled output is always placed in its one and only print queue the spool file. 

On the AS/400, spooled output can be placed in any one of numerous output queues (OUTQs). 

The CRTPRTF command is used to assign a report to a particular OUTQ by specifying the 
OUTQ for the report's print file. 

By looking at our default OUTQ, we were able to determine that the JOBLOG's used a print file 
called QPJOBLOG. All we had to do was assign the QPJOBLOG print file to a different OUTQ. 
Using the CRTOUTQ command, we created a special OUTQ, named JOBLOGS, in QUSRSYS 
library and then assigned the print file QPJOBLOG to it. 

CRTOUTQ OUTQ(QUSRSYS/JOBLOGS) 

CHGPRTF FILE(QPJOBLOB) OUTQ(QUSRSYS/JOBLOGS) 

The CRTOUTQ command does not attach the OUTQ to a printer, so as long as the print writer is 
not started for the JOBLOGS OUTQ, the JOBLOG's will not print. The JOBLOG's are all tucked 
away in their own OUTQ, essentially on hold. Yet, if we do need to display or print them, we 
easily can. 

One other suggestion. If you don't want to see the JOBLOG's on the WRKSPLF display when 
using WRKSPLF SELECT(*ALL), just use a printer device name in the device parameter. Then 
you will only see OUTQ entries that are assigned to the device name you specify. For example, 
WRKSPLF SELECT(*ALL PI) will display all entries on all OUTQ's that are assigned to 
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printer PI. If you want to only see entries that are not assigned to any printer, as in the case with 
the JOBLOG entries, just use *OUTQ in the device parameter like this: WRKSPLF 
SELECT(*ALL *OUTQ). 
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Selected from DataNetwork's electronic bulletin board, TELEFORUM 
From: M. D. of Van Nuys, CA To: ALL 

Anybody else sit in on that IR conference call today? If so, what did you think of it? One of the 
interesting things I got out of it is the ability to decrease your object code size by 2/3's with the 
CHGPGM commands option for remove observable information. Change this to *ALL. One 
program that is 56K on S/36, after migration was 478K. Now after disabling (observable info.) 
debug it is now 162K. 2.9 times larger than S/36 is much more acceptable than 8.4 times larger. 
We have been asking this question for 2 months. 

The other interesting point was the fact that the operator displays (display status commands) are 
stacking and will result in deeper invocation stacks which means larger PAG. All this will 
greatly impact performance. So what this means is you need to enter into the display command 
that you want, then totally exit out to switch to another display command. Sounds like poor 
planning to me. I hope they change this one. 

From: L. F. of Annandale, VA To: M. D. of Van Nuys, CA 

Before everyone rushes out to run a CHGPGM *ALL to remove observability on their programs, 
please be aware that by doing so you will not be able to run interactive DEBUG or get a 
formattted dump for the program until it is re- compiled. 

From: M. D. of Van Nuys, CA To: L. F. of Annandale, VA 

Correct. Good point. We will only be doing the GHGPGM *ALL against field ready modules, 
not programs currently in test mode. However, the other side is also that you just need to re- 
complile to get the DEBUG tables associated with the program back. Thanks for the help. 
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How weird is the AS/400? That depends on you. In general, the more you know now about your 
System/36, the weirder the AS/400 is going to seem. You won't lack for company, however. 

Much the same can be said about any programmer coming to an AS/ 400 after working on 
almost any other machine — IBM mainframe, DEC VAX, etc. 

To the ordinary application programmer, the biggest change is going to be using a database 
management system (DBMS) instead of a more conventional file system to maintain data. But, 
even given that DBMS has some unique features, the AS/400 is not alone in having a DBMS. 

Magicians Need Not Apply 

If you are one of the "wizard" class who has significant knowledge of your former machine — 
System/36 or whatever — below the level of RPG or COBOL, though, then the AS/400 will 
present an enigmatic face. If you can program in assembly language, know the detailed formats 
of file and library directories, and are acquainted with operating system calls, modules and 
control blocks, the AS/400 is going to seem very short on secret nooks and crannies. 

A Tangled Web We Weave 

Looking at Ligure 1 only (not found in Resource Library due to the inability to display the 
graphic image), it is not obvious that this should be so. Some of the terminology might seem a 
little unfamiliar, but there is a reassuringly rich tangle of pointers connecting things. And these 
things look as though they probably correspond to the many and varied kinds of control blocks 
and other precisely formatted entities that figure so heavily in the operating systems of more 
conventional machines. But appearances can be deceiving. 

On a conventional machine, for example, a batch or spool queue might be represented by the 
operating system as a linked list of control blocks. Each such block might represent one input job 
or output report. Each such block might also contain, say, a pointer to or name of a spool file, 
from and to pointers into that file to define the extent of a job or report, pointers to the preceding 
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and following control blocks that might make up additional parts of the spool queue definition, 
various control values such as form type, and various status flags. 

The system-level documentation would show the precise format of such a block. The offset in 
bytes, relative to the start of the block, for each of its pointers, control values and flag bit bytes 
would be noted. So would the precise significance of each individual bit in any byte designated 
as holding status flags. The locations of pointers to the list of queue control blocks — in the 
operating system and/or within application and system programs — would also be carefully 
marked out. 

A programmer with access to an assembler and to manuals containing this level of 
documentation could write an enormous variety of useful things — a number of particularly 
expert System/36 programmers have done just that over the years. Such useful efforts include 
special utilities and callable routines to enhance the function of application systems. But it is also 
true that a programmer who writes code that goes poking around in the bowels of the machine's 
operating syste m, also runs the risk of inadvertently scrambling the entire computing 
environment. 

Private - Keep Out 

The operating system-level entities on an AS/400 — and everything else for that matter — differ 
from usual practice in two important ways. First, there is no assembler available for the AS/400. 
Second, the details of system-level entrails are not publicly documented. 

But even if you were to bootleg an assembler and puzzle out the internal economy of every 
software entity on the machine, you could still not do the kinds of peek-sneaking and change¬ 
poking that have long been commonplace on other machines. The AS/400, and its architectural 
predecessor, the System/38, were designed with reference to many of the principals of what has 
come to be known as object-oriented programming. 

The primary idea of object-oriented programming is, in brief, that every distinct logical entity in 
a software system should be formally defined as a named type of object. Programs — which are, 
themselves, a type of object — can only know or change the content of a defined object by use of 
a formal interface to the object. 

If you like, you can think of the software environment of a typical computer — such as the 
System/36 — as being a lot like an old-fashioned general store as compared to the AS/400's 
supermarket. In a general store, all of the food and goods were generally visible; stored in barrels 
or bins without boxes or wrappers. In a modern supermarket, of course, nearly everything is 
packaged. You can only affect the goods inside by going through the intended package openings. 

Black Boxes 

Why all this formalism and mystery? Flexibility. The object-oriented programming idea had its 
origins in work done on modular and structured programming. It was found by, among others, 

Larry Constantine and Glenford Myers, that programs should, as much as possible, be composed 
of single function modules that interface to one another only through short lists of scalar 
parameters. Such programs tend to be easily debugged, very reliable in service, and easily 
modified — all very desirable properties for an operating system. In the language of structured 
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design, the modules of such programs are said to exhibit strong cohesion and minimal coupling. 

Also tied up into object-oriented programming is an idea David Parnas dubbed "data hiding." A 
more accurate term might be "structure hiding." The idea is that no calling module should need 
to know just what sorts of internal data structures and algorithms a called module uses to do its 
job. 

Consider, for example, a rudimentary spelling checker. All this module has to do is accept a 
short alpha string and return a yes/no flag that tells whether or not the string corresponds to any 
word in the English language. Such a module might store its English word list linearly, and 
check for matches via a binary search algorithm. It might also store such a list as some form of 
minimal tree structure, using a tree traversal algorithm to do the search. The point is that, so far 
as any calling module is concerned, the internal data structure and search algorithm employed do 
not matter. 

Chaperoned 

A further safeguard employed extensively by the AS/400 is the incorporation of a second idea 
closely associated with object-oriented programming called capability-based addressing. In its 
purest form, capability-based addressing would check every program request for access to, or 
modification of, any object against some kind of permission profile to insure validity. Capability- 
based addressing blocks any such operations for which no permission has been granted. 

The AS/400 offers an extensive security system that allows the conscientious shop the 
opportunity to very precisely limit what each user can and can't do to each object on the system. 
Objects can only be created, changed or deleted by specific command. This includes, most 
especially, files and program members in libraries. The number of object manipulation 
commands available on the AS/400 is very long and very exhaustive. Space limitations prohibit 
even listing their abbreviated names. 

Which brings us, once again, back to that thickish net of interconnected objects in Figure 1 (not 
found in Resource Library due to the inability to display the graphic image). We know that only 
the logical content — not the physical storage representation — of these objects is available to us. 

We also know that we have to ask nicely — and through official channels — before we can 
change any item in any of them. But what are they? What do they do and how do they fit 
together? 

Roll Call 

A few of the items shown are hardware — workstations, printers and comm links. Some others 
are also familiar as a consequence of their having counterparts on the System/36 — spool read 
spool readers and writers, batch job queues and spooled output queues. 

The user profile is the working beat cop of the AS/400 security system. A user profile object 
contains, for each user: the user's name and password; an auxiliary storage limit; a highest 
spooling priority; pointers to default message and output queues; a pointer to a job description 
object containing the defaults for the user's jobs; a specification that can limit any other user's 
ability to access the profile and lists of objects owned by and authorized for use by the owner of 
the profile. 
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Optional items include: the name of an initial program to run immediately after a user logon; 
several items that define whether or not the user is a member of a group of users with whom 
certain objects are to be shared; an accounting code for use-metering and chargeback purposes; 
and lists of any special operator or administrator permissions enjoyed by the user. These latter 
include the ability to perform various manipulations to spool readers, queues and writers; 
subsystems; jobs; and AS/400 Office objects and permissions. 

Job description objects define the general or default characteristics of any jobs that reference 
them. They can contain a default user name or a specification that the user name in force for a 
job is to be the name of the user invoking the job. The limits set by the associated user profile 
apply to jobs that reference such a job description. For batch jobs, there is also a pointer to a 
batch queue. 

Other items in a job description include: job and output priorities; an output queue pointer; a 
default printer specification; routing data which controls what program runs first when any job 
using the description is started; any request data that is to go on the job message queue; and an 
initial library list. 

On the AS/400, a user may have access to objects in more than one library. The library list 
specifies the order in which these multiple libraries are to be searched for objects referenced in 
the course of a job. 

Soloists And Teams 

As for jobs themselves, they are programs or sequences of programs executed by commands 
entered from workstations or by a file of commands submitted to a batch queue from a 
workstation or communications line. An interesting capability available to workstation users is 
the so-called "group job." A group job is a ki nd of shared session. Up to 16 different jobs can be 
invoked as a group. If a user is configured to start a second interactive session with the System 
Request key, another 16 group jobs can be supported simultaneously. Group jobs can pass data 
among themselves through use of a 512-byte group area that is common to all jobs in each group 
of up to 16. 

Only one job in a group can be active at any given instant. But a user can switch from one to an 
other via the ATTN key and a menu. A straight forward use of group jobs is to allow on-line 
order taking or service personnel the ability to interrupt an on-going data entry task to inquire 
against customer and order files upon phone request. 

As only one such job is "live" at any instant, group jobs are not a form of true multi-tasking, but 
the capability is useful just the same. Several of the low-end, run-multiple-programs-at-a-time 
products for the PC produce roughly the same effect on desktop hardware. A PC main memory 
full of "pop-up" terminate-and-stay-resident utilities also provides much the same group job 
effect on a PC. 

Pipelines 

Work entry objects are associated, on a one-to-one basis, with any object that can be a source of 
jobs. Each workstation has a work entry, for example. So does each communications link and 
each job queue on an AS/400. Finally, work entries can exist for jobs that are to be autostarted, 
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under appropriate circumstances. 


Each type of work entry has different contents. Autostart work entries have only a name for the 
job that is to be started and a pointer to the job description that will define its runtime 
environment. 

Job queue work entries hold the queue name and parameters for the maximum number of jobs 
from the queue that can be active at once and the maximum number of jobs of any given priority 
level that can be active at once. By making the first of these parameters larger than the second, 
you can insure that a constant influx of new, high priority jobs will not result in lower priority 
jobs being absolutely blocked from running. 

A workstation work entry has the workstation name, the name of the job description that is to 
define any job originated on that workstation, a limit parameter setting the maximum number of 
jobs submitted through the workstation that can be simultaneously active. 

A communications work entry holds a device description and remote location name identifying 
the far terminus of the link. There is also a job description pointer, a default user specification 
and a mode name. 

Subdivision 

A subsystem description is mostly pointers to other types of objects — especially work entries. 
When a subsystem is started up, all the devices referenced by its work entries become available 
for use. All autostart jobs specified in work entries contained within the subsystem are initiated 
also. 

Many shops have found it useful to define separate subsystems for each category of job source — 
all interactive jobs via a subsystem that owns all the workstations; all batch jobs via another 
subsystem that owns all the batch queues; and telecommunications, including workstation pass 
through, APPC/APPN via a third subsystem that owns all the comm links. IBM supplies a 
system con- figuration that implements such a compartmentalization when it is IPLed. 

Subsystems also specify how many simultaneously active jobs they will handle and in which 
defined main storage pool those jobs will run. 

Finally, subsystems point at objects called routing entries. A routing entry is, in essence, an 
ordered pair of a compare value and a pointer to a program. When each job starts, its routing data 
is compared to the compare strings in the routing entries for that subsystem and the program 
whose name is associated with the matching compare string becomes the first program to run in 
that job. 

A typical subsystem has only one routing entry. For most interactive jobs, the default routing 
data picks the system program (QSYS/QCMD) that displays the main system menu and runs the 
command processor. By making your own routing entries, though, you can cause your own 
programs to run just prior to the initiation of selected jobs, In future, the routing process will be 
the mechanism via which the SAA-standard REXX procedures language takes its equal place 
alongside the existing AS/400-specific CF command processor. 
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Understanding what a subsystem is, then, the object called a system is basically a collection of 
storage pool definitions and pointers to subsystems. Each system object specifies one subsystem 
as the controlling subsystem. At IPL time, the controlling subsystem is started first and, in turn, 
starts all the other subsystems defined for the inclusive system by initiating an autostart job for 
each one. 

Pool Party 

Storage pools are logical subsets of the total main storage available on an AS/400. Pools can 
have activity levels defined that specify the maximum number of simultaneously active jobs that 
they will accommodate. There are always at least two pools defined; a machine pool that holds 
the portion of OS/400 that must remain memory-resident to assure good performance, and a so- 
called base pool, named *BASE — pronounced STAR-BASE — in which all user jobs can run. 

Many systems are configured with two additional pools; a small one to run spool readers and 
writers, and a large one to handle interactive jobs. Under this arrangement batch jobs are run in 
*BASE. Pool allocations and activity level specifications have important effects on total system 
performance. The typical setup just described does not always do a good job of maximizing 
throughput. 

A Touch Of Class 

The object called class influences a job via the routing entry. When a job picks its routing entry it 
also, optionally, picks a class. A class object specifies a number of important parameters related 
to the run-time behavior of the program(s) in the job. These include run priority, time slice, 
maximum wait time for such things as locked records, maximum processing time and maximum 
disk storage use. 

The AS/400 is a virtual memory machine. The whole program does not have to be memory- 
resident at once to run. Pieces of code or data not in memory when referenced are paged in after 
the program is interrupted. When a program is running and has enough memory, it tends to 
develop a so-called "working set" of very frequently used code and data pages that mostly don't 
get paged out of memory. When programs hit points at which they incur long waits — think- 
before-type user time or waiting for a locked record, to cite two examples — the system can run 
more efficiently if the entire working set is paged out for the duration so other programs can use 
the space. The class object has a purge flag that indicates whether this letting go is to be done. 

Global Reach 

In addition to being a virtual memory machine, the AS/400 also runs its programs re-entrantly. 

That is, the executable instruction part of each program does not change as it runs, and can, 
therefore, be shared by many simultaneously active instances of itself. Each such instance, 
though, needs a private copy of all buffers and data areas used by the program. These execution 
contexts for re-entrant programs are called process access groups or PAGs. 

In addition to subsystems and all of the subordinate objects that hang off of them, a system 
definition also includes many parametric system values that define important aspects of the 
computing environment. Date, time, and certain format specifications for each are included in the 
system value roster. Of more consequence, though, are values defining such things as activity 
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levels the maximum number of jobs that can be simultaneously active in main memory. 

In general, IBM tends to ship systems with these values set to suit only the low end of the 
product line. The default activity level of the *BASE pool for a BIO, for example is three. 

The initial number of active jobs to allocate storage for (QACTJOB) is 20. The storage referred 
to is in the system tables that are part of the machine pool allocation. If you know your system is 
going to be heavily loaded very quickly after IPL, this number should be set higher for larger 
AS/400 models. 

The default system value for the number of additional jobs to incrementally allocate storage for 
is 10. If the AS/400 is anything like the System/38, this reshuffling of memory-resident internal 
operating system data structures is time consuming and kills production while it goes to 
completion. If you know the load will ramp up beyond 20 active jobs very quickly, modifying 
QACTJOB well upward should save some squawks from users. Of course one should also 
remember to set the maximum activity level (QMAXACTLVL) upward of the default value of 
100 if this is indicated also. On large AS/400s — B50s and B60s — this will almost certainly need 
doing. 

Conclusion 

The AS/400 is, in every respect, a much "roomier" machine than the System/36. It shouldn't take 
you early migrants from the System/36 long to get positively giddy at all the elbow room 
suddenly there for the taking. These architectural wide open spaces should easily compensate for 
whatever disappointment comes from finding that the "hatches and covers" to the AS/400's 
software internals are mostly welded shut. 

Dick Eagleson, CDP is a freelance writer and systems consultant in Hollywood, CA. 

REFERENCE: The AS/400 Work Management Guide contains more detailed information on the 
subjects covered in this article. 


Next 


Home 


Previous 









MIDRANGE 

COMPUTING 

HR PUBLICATIONS INC. 


TechTalk: AS/400 Tape Cartridge Tip 


February, 1989 

Copyright 1989, Midrange Computing 


by Jay Ramboldini 

From Jay Ramboldini, of Seattle, WA 

The first thing the AS/400 does whenever a cartridge tape is loaded, is to make what is referred 
to as a tensioning run. The tape winds to the end from where it was positioned at the time it was 
loaded, and then rewinds to the beginning of the tape. This insures that the entire length of the 
tape has equal and correct tension. So, if a tape is positioned at the very beginning of the tape, it 
must be wound from beginning to end, and then rewound. If the tape is at the halfway point, it 
must be be wound forward the remaining 50%, and then rewound. 

You can help minimize the amount of tape that has to be wound by always specifying * * LEAVE 
on any operation that reads or writes to tape. * LEAVE will leave the tape at the position it was 
last at when the operation is completed. 

* REWIND, on the other hand, will always rewind the tape back to the start. By leaving the tape 
in a more forward position, there will be less tape to read during the forward winding of the 
tensioning run. 

*LEAVE also saves time when you perform multiple sequential writes to the tape by leaving the 
tape in the proper position for the next write. * REWIND would perform unneccessary rewinding 
steps. 
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From Mark Grant of New York, NY 

The AS/400 internally works with numbers in packed-numeric format. This is the opposite of the 
System/36, where number are handled internally in zoned-decimal format. Consequently, it is 
much more efficient to define your file's fields in the AS/400 default format, packed numeric 
data. If you do not, extra instructions must be processed whenever a zoned-decimal field is 
encountered by a program. The Zoned-decimal field must be internally converted to a packed- 
numeric format before the system can do anything with it. 

But there is another consideration aside from the definition of fields in your in your files. This 
relates to fields that are defined in a program, such as calculation work fields, arrays, etc. Since 
only numbers with an odd number of digits fit neatly into a packed-numeric field, a numeric field 
that is defined with an even number of digits will result in extra instructions being generated to 
keep track of the unused high-order digit. 
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Selected from DataNetwork's electronic bulletin board, TELEFORUM 
From: R. L. of Mt Kisco, NY To: ALL 

I picked up a good tip on tuning your AS/400 while in S/36 mode at the local IBM branch office. 

Most 400's that ship to former S/36 sites come with the system value QSPCENV preset to *S36. 
This way, everyone who uses the system automatically starts in S/36 mode. The problem is that 
every job on the system runs in this mode, even if it is not a S/36 job (such as Office/400, 
Program Dev. Aids, etc. etc.). This setup slows these non-S/36 jobs. 

The solution is to set the system value to be *NONE using the CHGSYSVAL command, then 
IPL. 

For your users who want S/36 mode on all of the time, this can still be done by changing their 
User Profiles. Using the WRKUSRPRF command for each of these users, change the Special 
Environment parm on the 3rd screen to *S36. 

An alternative is to have users issue a STRS36 command when they want S/36 mode and 
ENDS36 to get out. When you set the user profile to *S36, you're stuck in S/36 mode for the 
duration of every session. ENDS36 does not work with the user profile set this way. 

The recommendation I saw also suggests changing the QPFRADJ parm to 0 (it comes set to 1) 
and to turn off the automatic config parameter. Both apparently use some resources. I have not 
checked these yet, maybe someone else knows what the effect is? The same writeup also 
recommends changing the controlling sub-system from QBASE to QCTL. I believe this has 
already been suggested on this board. 
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Selected from DataNetwork's electronic bulletin board, TELEFORUM 
From: C. R. of Las Vegas, NV To: ALL 

I have been converting a bunch of S/36 stuff to AS/400 native and I am having a little trouble 
with arrays. I cannot figure out how to declare an array with DDS so I have been declaring 
different fields with DDS and then just placing them in a data structure with the array to load. It 
seems like a lot of extra keying but I don't have any manuals yet to tell me different. Actually, I 
am getting more and more manuals all the time and I do use DDS reference to tell me how to 
code A specs. 

From: G. W. of Coachella, CA To: C. R. of Las Vegas, NV 

You are doing it right. DDS makes no provisions for arrays because storing an array as an array 
violates one of the primary rules of relational databases - a field can not have any internal 
structure; it is defined to be an atomic, irreducible unit of data. Therefore, arrays will always be 
program-defined, never externally defined as long as IBM sticks with the rules. 

From: C. R. of Las Vegas, NV To: G. W. of Coachella, CA 

For some reason that doesn't seem to hold water. DDS is not just for the description of physical 
file data. It is also for logical files and screen descriptions. In both cases arrays are very useful. I 
can understand wanting to keep data descriptions basic in the case of the actual data stored, but 
retrieval and display should allow complex formats. 

It just seems that I lose the advantage of externally describing my files when I have to describe 
them again in the program to equivalence them to an array in a data structure. I suppose I would 
feel differently if I had had opportunity to create all of these files on the AS/400, but since they 
were built using the S/36 conventions I am trying to find quick methods of conversion. 

From: G. W. of Coachella, CA To: C. R. of Las Vegas, NV 
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Well - that's the reason. You cannot use SQL, DDM, DDS, DFU, IDDU, or QUERY to access 
array data. All those products are field-oriented and there is just no way to ask for "all the 
records in this file where AR,2 (for example) is greater than 87". The products were not designed 
to work that way. We have taken extensive advantage of the fact that the /36 is record-oriented 
and fields are just program-dependant names for the characters between two positions. Some of 
the stuff does not translate well to a field-based system (as you well know), but we do what we 
can. 

From: C. P. of San Mateo, CA To: C. R. of Las Vegas, NV 

You don't have to describe arrays as individual elements, if you are willing to give up the 
capability of using the individual elements in system-supplied utilities. That is, you can convert 
/36 files to A-specs, and define the array as one long (character) field, equal to the length of the 
array data. Then you would need an "abbreviated" data structure to do the equates. For example, 
array ARA, 12 elements, 5.0 numeric: 

I DS 11 60 ARA I 1 60 EXTARA 

where EXTARA is the name of the field in the A-spec. If you don't think you'll need access to 
individual elements, outside of programs, then you might get away with this for a while. 
Unfortunately, the best way is to define each element, and use the data structure to regroup. 

Using the DS is not quite as bad as it seems, though, since you can define the DS in a /COPY 
module or use external data structures to drag the definitions in when you need it. With 
externally described WORKSTN files, you will have to define array elements as separate fields, 
since you can't put field names like ARA,2 on the A-spec ( unl ik e what we can do on O-spec ). 
So, since you'll need to define the elements separately for WORKSTN files, you might as well 
go ahead and define them in phy. files that way, and write the DS once and for all. It all seems 
like a tremendous bother now, and it seemed that way 9 years ago also, when the /38 was young. 
However, the consequences of not defining the elements are unpleasant... it's tough to explain to 
users, clients, bosses, etc., why they can't use Query and so on to get at their data, since they may 
have developed some ideas about how easy and nice the new machine is, etc. I know it's a lot of 
work, but don't take shortcuts on this. Find out what the rules are, grumble about them, then play 
by them, because it's a lot more bother, later, if you don't. 

From: C. R. of Las Vegas, NV To: C. P. of San Mateo, CA 

I agree with you that it certainly is worthwhile to have data defined in the method that IBM 
expects. Then Big Blue will make it easier and more powerful to use. It isn't that I think there is 
something wrong with DDS. I just like using arrays and now I am in trouble for it. We sell show 
tickets at remote outlets. My point of sale program show available seating using 4 42 element 
arrays. Because SDA used to barf at too many out of order fields, I put them in order so that they 
print A,1 B,1 C,1 D,1 A,2 ... now DDS has renamed all the elements to non array variables and I 
will have to write in data structures for all the arrays. Biting the bullet and doing it is not so bad, 
but it looks so dumb! Maybe I should be using some of the AS/400 "sub field" for (or) sub 
records or something? Is it possible to write the elements one at a time to a screen and then write 
the screen to the terminal? Sending one line at a time puts terrible overhead on a remote network. 
I did consider the method you suggested but the arrays that I normally work with are numeric. I 
got in the habit years ago of defining all the total information about something in one array and 
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packing it into a record. Like payroll has arrays that tell all the YTD earnings/tax info and sales 
has arrays with accumulated sales/refund info. These arrays sometimes get big and are always 
packed. I was concerned that I might run into problems with either an alpha field length or the 
AS/400s "invalid data" bomb. Sometimes (I am sure I will find out why when I have a couple 
more books) I get a crash when I am trying to access S/36 records using AS/400 native 
applications like DFU 

From: C. P. of San Mateo, CA To: C. R. of Las Vegas, NV 

I'll try to cover a few things, let me know if it helps... As far as your 4*42 display, you probably 
are doing the right thing, that is, define them across the screen and group them in DS. For 

example, L ine 1 - A01 B01 C01 D01 A02.Dxx Line 2 - A06 B06 C06... etc, something like 

this. If you define a record format with the four lines that you need, then you will only need one 
EXFMT or WRITE operation to send all of the lines to your displays. I may have missed 
something, but that might be what you're after. I think you referred to using "subfiles" as a way 
to get around this. You can certainly do this, and eventually you will want to investigate using 
subfiles for this kind of repeating display - just be aware that subfiles can become fairly 
complex. As far as defining arrays in files as a character string, it seems that the maximum 
length char, string is up to 32000+ bytes. This doesn't mean that RPG won't choke on it; it will 
probably give some message about assuming that this is an array or data structure, etc. So you 
might be able to define a complete array as one long character string, and break it out in the 
program. If you're pretty sure that you won't ever need to get at array elements, externally, then 
there is no compelling reason to define every array element externally. Just be aware of what 
you're getting into. As far as problems with DFU, I seem to remember the same thing happening 
on the S/38 when we used DFU to access records that contained packed arrays defined as a long 
character string. There was some execution-time DFU option to prevent the error, but I can't 
remember what it was, and am not yet very familiar with MOO DFU. Seems that DFU read the 
packed data and thought we were trying to fool around with screen attributes and control bytes, 
etc. If I can remember or find the option, I'll let you know. Try lots of things! Usually, anything 
that could be done on the /36 can be done on the MOO, most time easier, some times a little 
differently. You might also want to investigate multi-occurence data structures if you have lots 
of array-type things; these can serve to group similar arrays together. 

From: C. R. of Fas Vegas, NV To: C. P. of San Mateo, CA 

Thanks for the info you left me in that message. I think I must have not made what I am doing 
very clear, so here goes... On the screen I display four 42 element arrays using two columns, ie, 
the screen is in two parts. Something like this: 

Al,l A2,l A3,l A4,l II Al,22 A2,22 A3,22 A4,22 

Al,2 A2,2 A3,2 A4,2 II Al,23 A2,23 A3,23 A4,23 

on down for 21 lines. I have one line of headings and one line of prompts and one line of 
command key descriptions. Each element in the arrays corresponds to a key kept in another array 
not displayed. So, if the operator enters item 6,1 chain using a key 6. Of course I thought of 
using VFN and creating two screens (one for the left and one for the right) but that just seemed 
like extra work for nothing. Also, each time you output a screen to a remote site you have to wait 
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for the CTS RTS delay. This doesn't seem like much, but if the protocol converter has to do the 
waiting then my six terminals per converter have added 240 waits per screen. That can mean that 
my operators have an extra 24 seconds (approx.) between selections. Since they very often need 
to page forward or backward once or twice, I figured that would lead to unacceptable delays. 
Anyway, what I did to solve my problem was to create an externally defined data structure. I just 
copied the DDS from the screen source and sorted it into the order I wanted and built a file from 
it. Then I used that DS in my program and added the arrays to the DS description in the program. 
Since I had two more arrays from another screen, it added a total of 6 lines of code to my 
program. Now for the big job of rewriting the program to use externally defined screen specs. 

From: T. P. of New Orleans, LA To: C. R. of Las Vegas, NV 

It may be easier to define one output field on your format display with a length of 80 times the 
number of lines you want to display. So to display 21 lines you'd need 1680. In your program 
define an array with 21 elements of length 80 (screen array). Then define an array with 80 
elements of length 1 (line array). MOVEA your information (including "H"s) to the line array, 
then MOVEA the line array to the screen array. Continue until no more information - THEN - 
put out the screen with just the one output field (the screen array). 

Anybody out there doing this? 

From: M. D. of Van Nuys, CA To: T. P. of New Orleans, LA 

We use the technique you describe in msg #5600; however, the program is written in COBOL, 
but the format would be the same. It works great. RPG will work the same way I believe. 
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Selected from DataNetwork's electronic bulletin board, TELEFORUM 
From: E. M. of Torrance, CA To: ALL 

A few months ago I purchased ASNA's RPG-III for my System/36. While reading the manual, I 
came across the concept of Multiple-Occurrence Data Structures. Then, I read somewhere that 
they can be used to output columns of data to the screen — it seems like they work better than 
arrays...? I've been using two methods to accomplish this: 1. Displaying the whole screen at one 
time with arrays, naming them something like this: A,1 B,1 C,1 D,1 A,2 B,2 C,2 D,2 then doing 
a single EXCPT operation. 2. Displaying one line at a time with the variable-line# trick. How 
can this be done with MODS? 

So far the only thing I've used MODS for is to work with two-dimensional arrays (matrices) the 
few times that I've needed them. 

This must be extremely old hat for most S/38ers, but hey, it's new stuff to me! Would you care to 
enlighten this poor fellow? I'll appreciate any help you can give me. 

Prom: C. P. of San Mateo, CA To: E. M. of Torrance, CA 

I've used MODS on /38 and ASNA RPGIII. To write to variable line numbers, just set up a loop, 
stepping through the MODS and moving to the line. For example: 

1 DO 10 N N OCUR MODS ( move/z-add MODS fids to wkstn fids ) ADD 1 VLNO 
EXCPTSCNLIN END 

Something like that. As soon as you use the OCUR, then you have access to the fields in the 
MODS for that "occurrence". It's pretty much the same as setting an index on an array, in that 
you have access to that specific piece of data. Of course, the advantage of the MODS is that you 
get access to many pieces with one setting, instead of indexing lots of arrays. 
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From: E. M. of Torrance, CA To: C. P. of San Mateo, CA 


I guess the coding you suggested can be used when the program needs to access the displayed 
information AFTER it is displayed, like in further calculations. If this is not a requirement (it 
usually isn't in inquiry programs), there is really no point in storing the displayed data either in 
arrays or MODS. I've been using the variable-line method for years WITHOUT using arrays at 
all; as a matter of fact, I started using this method because I didn't want to bother coding arrays at 
all — they are sort of a nuisance, aren't they? 

But, as you suggested, MODS can be used very effectively for storing the whole shebang for 
future use. Thanks for your reply. 
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by Openbbs Contributor 

Selected from DataNetwork's electronic bulletin board, TELEFORUM 
From: N. P. of North York, Ontario To: ALL 

The crew in Rochester have given us a nice Christmas present on the AS/400. Once you have 
updated to release 1.2 you should download and apply microcode PTF MF00364. The 4 page 
cover letter includes a copy of the "Key-Ahead User's Guide" dated 12-19-88 that gives you all 
the details. Basically you now have 32 key buffering available on all 5250 type devices 
(probably IBM only) that are attached to a twinaxial controller. After using a PC for years with 
this feature it's great to be able to use it at any workstation. 
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by Dick Eagleson 

System/36 programmers moving to an AS/400 are in the interesting position of being the last 
major population of data processing professionals to face "database anxiety" - the fear that 
everything they know about programming is about to be rendered null and void when this 
database thing, whatever it is, arrives. The jitters are not much helped by the common knowledge 
that, just as on the System/38 before it, use of the Database Management System (DBMS) on the 
AS/400 is not optional. 

Not Fatal 

Worriers may find reassurance in the fact that mainframe programmers, many of whom had 
exactly the same DBMS anxieties a decade or more ago, lived through the change and even 
prospered. The impression some of them had at the time, that database management was some 
tremendously complex and tricky undertaking that required special gifts the ordinary 
programmer didn't have, simply failed to withstand reality testing. 

Mainframe database management — with the notable exception of IBM's IMS — did not turn out 
to be a perverse exercise in overcomplication. The AS/400's database facilities are even more 
approachable. Experienced System/36 programmers need not fear an ordeal. The dirty little 
secret of database-oriented programming is that it's not especially hard. With a little experience, 
in fact, you will prefer it. 

What Is It? 

Even assuming it won't hurt, though, just what is database management and how does it differ 
from the file systems you are all used to? The basic idea of all DBMS's is to provide an interface 
to your data that is entirely symbolic, specifying only data names or desired characteristics. Most 
particularly, database management does not mean that the old, familiar ideas of file records, data 
fields, index keys, etc., go out the window in favor of utterly alien replacements. As you shall 
see, the DBMS idea just takes all of these concepts, strips them down to their essentials, and 
regularizes them a bit. 
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To begin with, take this business of a symbolic interface. When you design systems using 
conventional files, you are already employing a partially symbolic interface to data. Files are 
accessed by using their names in OCL statements, and individual records can be gotten with 
symbolic operations such as READ or CHAIN. This interface is symbolic in the sense that you 
do not have to specify things such as device addresses, cylinder, track and sector numbers, and 
sector offsets to get at indexes and files. The symbolic nature of the System/36 file interface 
hides these details of physical storage. 

A record, though, is the lowest level of discrete data item that a conventional file system, like 
that on the System/36, will define. The individual data fields that make up any given type of 
record have to be specified in terms of their relative positions in the record. Having to specify 
"from's and to's" in the input or output specs of an RPG program is conceptua lly the same, at the 
field level, as having to specify device, cylinder, etc., to get at files and records. When accessing 
data via a DBMS, then, the data is always asked for by name — right down to the level of 
individual data fields. 

Data Independence 

Disconnecting the access to files, records and fields from questions of low-level formatting is 
often called "data independence." The term is a bit limiting though. It is not just the data that 
achieves several kinds of independence, but also the programs that reference it. 

First, consider the data. If data fields are recognized by the system as having an existence that is 
independent of the field definitions on the input or output specifications of RPG programs, then 
certain other things must follow. The first is that file, record and data definitions should be made 
only once, and should be made in a way that can stand alone, without reference to what is coded 
in any one program. 

DDS 

The System/38, and now the AS/400, use a distinct coding form called a Data Description 
Specification (DDS) to define files, records and fields. DDS is, in essence, a programming 
language to describe data. Creating an actual data file using its DDS description is exactly like 
compiling a program. Just as a program can be described in a source member, but does not 
become "real" — in the executable sense — until it is compiled, DDS specs can be said to contain 
the idea of a file, but until they are "compiled" with an appropriate create command, the file, 
itself, does not exist. 

One of the consequences of DDS being, in effect, an entire, special purpose programming 
language in its own right, is that — just like RPG or COBOL — it can have its own way of doing 
things. An especially relevant example of this is the matter of field names. RPG programmers are 
used to thinking of 6-character field names as being the natural order of things. COBOL coders, 
who have been able to play with names up to 30 characters long throughout their careers, know 
that six is not a magic number. But both may have to get used to the fact that DDS allows up to 
10 characters for both file and field names. An additional small surprise for RPGers is that, in 
DDS, record types must also have names. 

Heave-ho To "From's and "To's" 
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To any RPG programmer who has ever had to laboriously recode the from and to columns on 
input and output specifications when a file or record definition changed during system 
development, DDS offers blessed relief. Since, in the database way of looking at things, 
everything starts with field definitions and builds up from there, fields only have to be named 
and defined in terms of type and length. The "from's and to's" are implicitly determined from the 
order in which you specify the fields on DDS source lines. 

An RPG program that employs externally defined files, then, never has to know from's and to's 
to get data from a DDS-defined record. The DDS compiler could just as well have been designed 
to arrange fields in the physical file records in the opposite order from the way you specify them, 
in order by length, in alphabetical order by field name, or in random order. The DDS processor 
does not, in fact, do any of these things, but the point is, your programs wouldn't care if it did. 

On the AS/400, as on the System/38 before it, a program that wants a given field from a given 
record will still get it. The matchup is done by name, not by specifying the location of the field in 
a record. 

Program Independence 

If the AS/400 database lets data definitions be independent of what is coded in programs, then 
the programs are also insulated from what may be coded in DDS. In particular, RPG and 
COBOL programs don't have to worry about such physical formatting details as what the length 
of a particular record type happens to be, so long as that record was coded in DDS. 

If a given RPG program, for instance, uses only three fields in a record type that contains 15, 
then that record type can be modified to contain a sixteenth or a seventeenth field without 
requiring any rework on the program — no "from's and to's" to worry about, and no record length 
declaration either. This will be true even if the new fields inserted into the DDS record definition 
don't go at the end, but are slipped in between existing fields of the revamped record definition. 

Like OCL 

How is all this done? By matching up names instead of "from and to" positions. The process is 
exactly equivalent to what you do with OCL statements when you need to match up a file's real 
name with the name coded in the program if the two names are not the same. 

An RPG program has to call any field it uses by a 6-character name. The connection between the 
up to 6-character names used by RPG programs and the up to 10-character names that can be 
used in DDS definitions is established, where needed, by a special extended use of the RPG input 
(I) spec. The idea is to code a cross-reference list that relates the up to 6-character field names 
for use in an RPG program to the corresponding up to 10-character field names that are known to 
the AS/400 DBMS. 

For each field with an "oversize" name that your program needs from a particular record type, 
you need to code a "stand-in" 6-character name in the usual place on the input spec. This 
shortened name is the one that your program will use when referring to the data field in question. 
The logical connection to the externally defined, up to 10-character field name is made by 
entering that name in columns 21-30 where coding for record identification criteria usually go — 
no from's and to's at all. 
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Voluntary Restraints 


Please note that this process of cross-reference mapping by hand is only called for if you actually 
define fields with names of greater than six characters when you define your database records 
with DDS. If you never use the extra four characters worth of name length available on the DDS 
forms, no cross-reference coding of I-specs is needed; your programs can directly access any 
needed fields by using the same names as the DDS definitions. 

On the System/36, when your programs call files by the same names as does the System/36's 
directory, you get to eliminate a name cross-referencing parameter from your OCL. On the 
AS/400, keeping your DDS-defined data names no more than six characters long is even better; 
the need for an entire special I-spec line is eliminated. 

In general, it is probably a good idea for RPG programmers not to use the extra four characters 
worth of data name length that AS/400 DDS makes available. To make it easier for you to 
remember to observe this limit, if you decide to, the DDS coding form is printed with delimiter 
lines at the 6-character and 8-character points within the 10-character field name specification 
area. The 8-character marker helps you keep file names within the limits imposed by RPG 
coding forms in the same way the 6-character marker helps with field names. 

Short Course 

By now you should have a good grasp of the basic ideas of database management and data 
independence. As you should appreciate, there is nothing dark and mysterious about these 
notions at all. At its simplest, nothing more is involved than taking symbolic accessing and 
name-matching ideas that you have been using with files and records for years, and moving their 
application clear down to the individual data field level. 

There is more to the idea of data independence than there is room to present here at one sitting. 
The subject will be returned to in subsequent articles. But you may rest assured that nothing that 
is to come about data independence is any more abstruse than what we have already covered. 

Normalization 

But there are other things out there in "databaseland" that many folks find mysterious and/or 
intimidating. An item of terminology that comes up fairly often in the database literature is 
normalization. This is a word usage that came out of research work on relational databases. If 
you are going database, say the experts, be sure to normalize your files first. Sounds like good 
advice. After all, who wants to go around with abnormal files? 

Again, we find one of those dirty little secrets in which things that sound scary turn out to be 
rather mundane when the light shines on them. As to this question of normalization, the first 
thing you should know is that normalizing files is not just a good idea for DBMS users, but for 
everyone. Second, if you are a competent system designer, the odds are good that your files are 
normalized, or near enough as not to make much difference. 

Normality 

Along with the general term "normalization," articles and discussions about database 
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management discuss various "normal forms" — usually 1st-, 2nd- and 3rd-normal forms — that 
file record definitions can be in; the higher the normal form number, the better. Keep in mind 
that relational DBMSs only allow one record format per file, so when a file is referred to as 
being in some particular normal form, this means that its one-and-only record format meets 
certain conditions. 

Relational Rules To Follow 

To an RPGer, it might seem that the relational DBMS idea of only one record format per file is 
restrictive or even unnatural. It really isn't. Designing your files, at least conceptually, with only 
one record format per file allows a certain analytical clarity that can get lost if you start worrying 
too early in a design exercise about header records and eight kinds of needed trailer detail for 
some big report. Don't worry. Be happy. Design with the relational one-format-per-file guideline. 
The AS/400 database has some non-relational extensions, including a way to make a bunch of 
single-format files look like a traditional header-and-multiple-detail type when convenient. More 
about that in a future article. 

Back To Normal 

First-normal form requires that each field cannot be subdivided without loss of meaning and that 
there be no repeating groups of data within a record. Any elements of repeating groups must be 
placed in a separate file. Second-normal form is what most files in well-designed systems are in. 
Second-normal form sets the rules for key and non-key fields in a file. To be in second-normal 
form, a file must meet first-normal form rules, and each non-key field of a record must be 
functionally dependent on the key field or composite of key fields. 

Keys 

Now for a bit of clarification — because when a relational database guru uses certain familiar¬ 
sounding words, they don't mean quite the same things as they do when a System/36 
programmer uses them. For example, when a relational DBMS person says "key," the word does 
not mean, literally, that the system maintains an index on a field or group of fields — although 
this will often be true. "Key" just means a single field, or a small group of fields, whose value 
will be unique for each record of the file. 

Repeating Groups 

This matter of "repeating groups" needs a little Windex applied to it too. A data item in a record 
may be entirely dependent on the key value for that record, but it may not be the only data item 
of its kind that is similarly dependent. In a personnel master file, for instance, the name of the 
college attended depends on the employee ID that keys the file. The problem is, an employee 
may have more than one legitimate datum of this kind to record; many people have attended 
more than one college. 

The relational data model advocates first formalized the idea, perhaps, but it is still true for non¬ 
relational, and even non-database, file systems — whenever you run across a situation in which 
there can be a variable number of some kind of dependent data item, you have identified 
something that needs to go in a new file of its own. The key of the new file needs to be a 
combination of the key to the old file, plus some new identifier datum that is uniquely associated 
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with each instance of whatever the variably-occurring item is. In the case of our "college 
attended" example, the new file might be called "educational history" and be keyed by a 
combination of employee ID and date of enrollment. 

Abnormalization 

The lazy way to deal with such situations is to define some sort of array in the original master 
record to keep such data in. The problem is always in picking a size for the array. Anyone who 
designs a personnel master file with three slots for college data is just about guaranteed to 
eventually encounter a new hire with a triple undergraduate major, three masters degrees and a 
pair of doctorates, all from different institutions. If the file has to keep track of elementary and 
high schools as well, beware of the army brat with a transcript as long as your arm. 

This sort of laziness is especially easy to indulge if the designer is working on a system whose 
file management capabilities include support for variable-length fields, records and arrays. In 
some respects, then, the System/36's rigidities in such matters have been a blessing in disguise to 
system designers. Even if completely ignorant of the ideas about file normalization that came out 
of relational database research, designing within the limits of the System/36's relatively simple 
file system has had the effect of making a lot of designers think in file normalization terms even 
if the word was not part of their vocabularies. 

Holy Grail 

To a relational zealot, the holy grail is usually 3rd-normal form. A file in 3rd-normal form has a 
simple or compound key and everything else in it is not only determined by the key, but only by 
the key and not by any subset of the key or by any other value within the file's record definition. 

Relational Rules To Break (sometimes) 

3rd-normal form record definitions — while they have a number of nice characteristics from the 
standpoint of the mathematics underlying the relational data model — also have certain 
shortcomings when pursued single-mindedly in practice. 

As an example, consider a customer master file in a credit-checking application. Such a file 
might have records containing both credit card number and, say, California driver's license 
number — either of which might be used as the primary access key with no particular preference 
given to one over the other. The dependent contents of the record would be things such as name, 
address, etc. 

By the strictest reading of 3rd-normal form definition, this file should be forced to make a choice 
between one of those "candidate keys" and the other. Both are unique identifiers. You could 
arbitrarily say that driver's license number is dependent on credit card number, but the reverse is 
just as true. And every other data item in the record is just as determined by one as by the other. 
In this case, forget 3rd-normal orthodoxy and go with what works. 

In the case of addresses, rigid 3rd-normality might also yield odd results. City, state and ZIP 
code are all parts of a U.S. address, for instance. But city and state are also absolutely determined 
by ZIP code, and not just by the key of whatever file record the address is part of the definition 
for. Should you have a ZIP code master file in every application that uses addresses, so that other 
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master records only have to contain the ZIP, while the ZIP master contains the city and state? 
Maybe yes, maybe no. If your application is basically to support some function such as direct 
mail solicitation or marketing, the answer might well be "yes." If the address is recorded only for 
the purpose of mailing out bills, though, the case for a separate ZIP code master is probably not 
as compelling. 

Oh yes, useful running subtotals, such as the year-to-date value of orders or payments received 
that you might reasonably keep in a customer master file's records, are also of dubious standing 
in a doctrinaire 3rd-normal file definition. There are also some other objections to such subtotals 
from the standpoint of other aspects of database theory, but discussion of these will be deferred 
to a future installment in this series of articles. 

Much Ado About Nothing 

The last item of database terminology that should be mentioned is the idea of nulls. Some 
DBMS's, especially relational ones, support a data type called "null" that can be used to indicate 
when the value of some data item is not known. The personnel record for an employee who was 
a foundling and was raised in an orphanage, for instance, might reasonably have null values in 
the fields that would normally contain mother's maiden name, place of birth and date of birth. 

The concept of null in database usage is important because on a system which does not support 
null representations, there is no way to tell the difference between field values that represent a 
known value of zero or blank, and a value which is simply missing or unknown. Many query 
language systems — including the upcoming ANSI standard SQL — allow queries in which this 
distinction is important. The non-standard SQL on the AS/400 will not be one of them, though, 
until the machine's built-in database system is revamped to support null representations also. 
Currently, the AS/400 takes after its System/38 forebear in that it does not support nulls. 

Coming Distractions 

The concentration here has been on old familiar concepts like file, record and field. This is 
because data in these tabular forms — plus text from office applications — is the kind that you 
have been used to dealing with on the System/36. But in the future, it is said, the AS/400 will 
handle voice, video, images, generated graphics, etc. 

Just how this is going to be arranged is unclear. Most probably, these complex data forms — 
many of which are conceptually two- or three-dimensional — will simply be made definable as 
complex field types in record definitions that otherwise follow the general rules of database 
design that originated for strictly tabular data. 

Since it is hard to see how it will be possible to meaningfully "index" such complex data forms, 
the job of usefully incorporating these new entity types into future applications will probably 
make your mastery of database design for simple, one-dimensional tabular data a continuing 
matter of critical importance. Future articles in this series will broaden pen the treatment of this 
increasingly fundamental DP skill. 

Dick Eagleson, CDP is a freelance writer and systems consultant in Hollywood, CA. 
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by Midrange Computing Staff 

The AS/400 File Information Data Structure (INFDS) provides a wealth of information for each 
file used in a program. This information includes such things as current print line, cursor 
position, display station type, and current record number. If you came from the System/36, your 
mouth is probably watering by now since this type of information was only available by the use 
of Assembler subroutines. 

The good news is that all this data is available with any high level programming language. The 
bad news is that it is not readily apparent just where in the INFDS all the data can be found. This 
article will translate into English what the manuals are attempting to tell you. Not only will we 
show you how to decipher the information in the manuals, but we will also include a reference 
sheet (not included in RESOURCE LIBRARY) with the locations of some of the more common 
and often used file information items that are available to an RPG/400 or S/36-compatible RPG 
II program. You should make a copy of it to place with your other reference material. 

We also want to mention that we have created a source member (RPGINFDS) in the 
DataNetwork AS/400 RESOURCE LIBRARY that includes an RPG Input specification for 
every INFDS field available to RPG. You will be able to easily include this into any RPG 
program and avoid going to either the manuals or the reference sheet. 

General Information About INFDS 

You have probably all coded an INFDS data structure before, but we'll start off with a quick 
refresher for those if you who are not familiar with it. 

First of all, you can create an INFDS data structure for any file defined in a program, with an 
exception for System/36-compatible RPGII programs, which can define INFDS only for 
workstation files. This includes workstation files, data base files, printer files, etc. You just 
create an F-spec continuation line for the file with a 'K' in position 53, 'INFDS' in positions 54- 
58, and the name you want to give the associated data structure starting in position 60. This 
continuation line must immediately follow the file's F-spec. If more than one file is going to use 
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the INFDS, be sure to make each data structure name unique. 

The next step is to define the data structure in your I-specs. There are several special keywords 
that can be defined in this data structure, such as *STATUS, *SIZE, and *RECORD, that will 
give you some information about the file. These are fully covered in the RPG/400 Users Guide, 
Chapter 4, File Exception/Errors section. But the real bulk of information is found by specifying 
the From and To positions of other areas in the data structure. This is the part we are going to 
help you with. 

For more complete information about defining INFDS, see the RPG/400 User's Guide, Chapter 
4, under the heading File Exception/Errors, subheading File Information Data Structure. For 
System/36-compatible RPGII programs, refer to Chapter 7 of the System/36-compatible RPGII 
User's Guide under coding the INFDS Data Structure, in addition to the RPG/400 manual. 

Where to Find the INFDS Field Information 

The manuals divide the available INFDS information into three main categories: 

File Feedback Information Area 
Open Feedback Information Area 
Input/Output Feedback Information Area 
Common I/O Feedback Area 
Device Dependent Feedback Area 
for ICF and DSP Devices 
for Printers 
for Data Base files 

To find information on any of these areas, refer to either the RPG/400 User's Guide or the Data 
Management Guide: 

RPG/400 User's Guide, Chapter 4 

-File Feedback Information Area 

-Open Feedback Information Area 

-Common I/O Feedback Area 

Data Management Guide, Appendix A 

-Device Dependent Feedback Area 

Some fields found in the RPG/400 User's Guide will refer you to the Data Management Guide 
for further information. 


Next 


Home 


Previous 








The chart in the RPG/400 User's Guide gives you the actual positions of the fields that can be 
found in the File Feedback Area, Open Feedback Area, and Common BO Feedback Area. But, 
when you refer to Appendix A of the Data Management Guide to find any field positions in the 
Device Dependent Feedback Area, you are faced with offsets, rather than actual field positions. 

To determine the actual starting position of a field in this area, just add 367 to the offset. As an 
example, find the field "Number of key fields" in the Data Base BO Feedback Area (as of 
Release 1.2, this is on page A-17). The offset is 21, with a length of 1, so you would code your 
input spec with a from position of 388 and a to position of 388. (Note that binary fields with a 
length of 15 are two decimal positions long, and binary fields with a length of 31 are four 
positions long.) 

As you look through Appendix A, you will see that the other areas that were in the chart in the 
RPG/400 User's Guide are also there — but with offsets instead of actual positions. To avoid any 
confusion, ignore those offsets; just use the positions from the RPG/400 User's Guide. The only 
time you will ever need to reference these particular charts is when you are referred here from 
the RPG/400 User's Guide for more information. 

Here is a basic outline of the different area's positions in the INFDS: 

File Feedback Information Area 001-076 

Open Feedback Area 081-240 

Common BO Feedback Area 241-286 

Device Dependent Feedback Area (ICF,DSP) 367-446 

Device Dependent Feedback Area (Printer) 367-404 

Device Dependent Feedback Area (DataBase) 367-499 

Just One More Thing 

Just when you thought you had this all figured out, we have to explain one more thing to you. 

There is an RPG operation called POST. This lets you access information about another 
workstation (or your own for that matter) that is attached to the program. This should be a 
straight forward thing, but the way it works is a bit odd. Rather than placing the information it 
retrieves into its own area of the data structure, or even a separate data structure, it will overlay 
positions 241-528 with the information. The normal INFDS definitions for these positions no 
longer apply. It has it own field definitions, which can be found in the RPG/400 User's Guide, 
Chapter 4, section "Contents of File Information Data Structure After Post". This is basically the 
same information that can also be found in the Program Device Attributes section in Appendix A 
of the Data Management Guide, only it is re-hashed for RPG. 

POST will only give you values for the special keywords in a System/36-compatiblRPGII 
program. Positional fields will not be returned. 

The Quick Reference Sheet 

On the next page is a chart that we have made up for you to keep as a quick reference of the most 
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commonly used INFDS fields, with the exception of the special keywords that you will 
eventually know by memory. This chart does not include any of the fields that become available 
after the POST operation code. 

The INFDSALL Source Member in the RESOURCELIBRARY 

As we mentioned earlier in the article, we have added a fully commented source member to the 
RESOURCELIBRARY which contains an input specification for every position in the INFDS 
data structure. Even the areas after the POST operation are included. When you need to access 
INFDS information about a file, just SEU include the needed statements of the INFDSALL 
member. 

References: 

RPG/400 User's Guide (File Information Data Structure) 

Data Management Guide (Appendix A) 

RPG/400 Reference 
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From DataNetwork staff: 

There is a very useful and very educational library on the AS/400 that gets very little attention. It 
is called QUSRTOOL. This library is supplied to you by IBM and provides you with well over a 
hundred programmer tools that you can put to use and also leam from. These tools cover the 
whole range of AS/400 areas including PC Support, Work Management, Graphics, Storage 
Space Management, CL, and RPG. 

We will go into detail about this library in an upcoming issue, but you can get started on it now 
by reading the AAAMAP and CRTTAATOOL members in source file QATTINFO of library 
QUSRTOOL. 
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From DataNetwork staff: 

If you have an RPG program that WRITEs a record format with informational messages, such as 
"Now Spooling", etc., you will not be able to just WRITE the screen and expect it to always be 
displayed immediately. 

AS/400 workstation WRITEs are normally deferred until the next READ or EXFMT operation is 
performed. This method is used to help improve performance when multiple records are written 
to a display file before input is required. It is especially beneficial at remote sites. However, it 
can cause problems in the case where an EXFMT that clears the entire screen follows a WRITE. 
The user may never see a screen that was supposed to have been displayed. 

To get around this, specify the keyword FRCDTA in each record format that you want displayed 
immediately. 

You can also use the defer write parameter value of *NO in the CRTDSPF command, when the 
display file is created. However, this will cause all display records in the file to write 
immediately. 
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by Midrange Computing Staff 

From DataNetwork staff: 

To have your native program accept input when the roll keys are pressed, you will need to 
specify a response indicator with the ROLLUP or ROLLDOWN keywords in the workstation's 
DDS specs. For example: 

ROLLUP(82) ROLLDOWN(83) 

Beware, however, if you are using the special keyword *STATUS. It will not contain a valid 
status for the roll keys. Just reference the indicators to detect that a roll key was used. 
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by Midrange Computing Staff 

From DataNetwork staff: 

Sometimes on the AS/400 you have to locate an object and you have no idea in which library it 
resides. There is a command on the AS/400 that will help you to locate any object on the system. 
Not only will it find the object for you, but it will show you every occurrence of that object. This 
makes it also useful for finding duplicate named objects — something you must be aware of when 
setting up library lists. 

The command is DSPOBJD. You just use *ALL for the library name to search and *ALL for the 
object type. Each occurrence of the object will be displayed one at a time for every library in 
which it is found. 
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by Openbbs Contributor 

Selected from DataNetwork's electronic bulletin board, TELEFORUM 
From: A. T. of Spotswood, NJ To: ALL 

Is there a simple way to execute an OVRDBF command in CL, but use the work- station ID? 
Most of my procedures use the ?WS? to allow more than one user to run a report at once (e.g. 
Sort files). Any kind of unique substitution would work. 

From: C. P. of San Mateo, CA To: A. T. of Spotswood, NJ 

You might be able to use the RTVJOBA (Retrieve Job Attributes) cmd to get at the workstation 
ID. For example, RTVJOBA JOB(&WS). For absolute uniqueness, you will probably want to 
use the "NBR" parm of the RTVJOBA command, since this will return the system assigned 
unique job number. The JOB parm could be in use for more than one job, for example, if you are 
signed on twice at the same terminal. 
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by Dick Eagleson 

Last month I tried to show that this area of concern called database isn't anything that ought to 
cause a good System/36 programmer to run screaming for the door. If you like your system units 
white and your diskettes eight inches on a side, then welcome to the AS/400 and the wonderful 
world of database, brothers and sisters. You're going to get along just fine. 

Recap 

There won't be a pop quiz. But you should recall that a Database Management System (DBMS) 
is a file system whose defining characteristic is a completely name-oriented, symbolic interface 
between programs and data. 

Also recall that the relational database surgeon general has determined that unnormalized files 
are dangerous to your applications' health. Unnormalized files may contain arrays, repeating data 
structures and multiple record types. First-normal form (INF) files have a single record format 
and no repeating items or arrays. Second-normal form (2NF) files are INF files that have a key 
made up of one or more fields that is unique for each record. All other field values are 
determined by the key. Third-normal form (3NF) files are 2NF files where each non-key field is 
determined only by the key and not by any subset of key fields or by any other non-key field or 
combination of non-key fields in the record definition. When you are designing application files, 
3NF is a good thing to try to shoot for, but in a fair number of cases 2NF will do. 

Finally, the idea of a special null value, that represents missing or unknown data and that is 
logically distinct from a known value of zero or blank, is a concept supported by some database 
systems that you will not have encountered in using conventional file systems. 

Making Connections 

If it seems as though there must be more to database systems than this, you are right. One thing 
you have probably heard said about DBMS's is that they allow complex relationships among data 
items to be represented in ways qualitatively different than what you can do with conventional 
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files. So far, all we've talked about is breaking complex record definitions down into simpler 
ones. In terms of complex interrelationships, it probably looks like we have been going 
backwards. Where's the complexity? Where are the relationships? 

Prophets 

To an important degree, the answer depends upon whom you ask. The database world has been 
riven by warring sects since its inception. At present, the upper hand is clearly held by the 
"relationalists" who draw their inspiration from Dr. Edgar F. (Ted) Codd's landmark paper "A 
Relational Model of Data for Large Shared Data Banks" which appeared in the June, 1970 
edition of Communications of the ACM, the oldest and most prestigious computer science 
journal. 

Sputniks and Set-niks 

Codd's relational data model has its roots in a branch of mathematics known as set theory. Set 
theory, as all of you fellow Baby Boomers will recall, was the most visible part of that weird 
New Math stuff we all had to start learning in elementary school a couple of years after the first 
Sputnik went up. Surely you recall such deathless poetry as, "Given two sets {A,D,E,F} and 
{B,C,D}, what is their intersection and their union?" I guess I should be grateful that long 
division stayed in my school district's curriculum long enough for me to learn it. Set theory 
replaced learning how to extract roots with pencil and paper, however, and I never have picked 
that trick up since. But I digress... 

Codd was as good as his word. He established a relational model of data using set-theoretic 
math. Every implementation based on that model has departed from strict adherence to it in at 
least some small particular. In many cases the departures have been more substantial. 

The Book of Lists 

So what is the relational data model and how has its theory been compromised in practice? You 
already know that the relational model mandates single-format files — often called "flat" files — 
that have been normalized to a 3NF state. A relationally relevant item of intellectual baggage 
carried in from set theory is the notion of domain. 

In set theory, every set has members drawn from some defined domain. Our New Math nostalgia 
example used two sets whose members were drawn from the domain of alphabetic characters. 
The sets {0,1,2} and {A, 5, B}, for instance, are not drawn from this domain, but from a larger 
one that includes at least the single-digit integers in addition to the alphabetic characters. 

Another illustrative example is the poker hand, which is a set of five card values drawn from a 
domain of 52. 

The applicability of the domain concept to record formats is that the definition of each field in a 
record can be considered a domain. If a record is to include address data, for example, it should 
have fields for such things as street number, street name, city, state and zip code. 

Possibilities 

You can appreciate that all five of these items could also be the names of domains and that the 
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number of legitimate values for a domain would vary widely among the five. The least populous 
of these five domains, for instance, would be "state," which would include only the names of the 
50 states plus a few equivalent territory names such as the District of Columbia, Puerto Rico and 
the U.S. Virgin Islands. The zip code domain would consist of only those nine-digit zip codes 
that have actually been assigned as yet by the U.S. Postal Service. The city domain would, 
ideally, consist of a duplicate-free list of every city, town and whistle-stop name in the U.S. and 
its territories. 

The preceding examples should demonstrate at least two truths. First, it should be obvious that a 
database system that implemented the notion of domains would automatically have a great deal 
of data available with which to edit the correctness of individual field contents in proposed new 
or changed records. Second, it should also be obvious that, in many cases, an enormous amount 
of work might be involved in exhaustively defining the list of values that should make up any 
given domain. 

Domains Overboard 

In practice, almost none of the relational DBMS's ever implemented actually provides a 
mechanism for enumerating the membership of a domain or for taking advantage of defined 
domains to assist in editing and validating new or changed field values. The Structured Query 
Language (SQL), for example, which has been widely implemented as a relational interface to 
databases on a variety of systems — including, as of Release 1.2, a subset version for the AS/400 
— includes no concept of, or support for, the definition of domains. The underlying AS/400 
DBMS, on top of which SQL is implemented, is also without any explicit, built-in support for 
the idea of domains. 

Take Bytes In Big Bites 

Now we come to the thing which, more than any other, sets relational DBMS's apart from those 
built on other assumptions. All DBMS's recognize field and record entities. Most non-relational 
DBMS's also provide some set of operations that allow you to manipulate data in field-at-a-time 
or record-at-a-time quantities. The relational data model is unique in that the file is the basic 
conceptual unit of data manipulation. Individual fields and records in a relational database can be 
separately manipulated, of course. But such manipulations are done as special cases of 
operations defined to be capable of touching multiple records or fields at once. A field, after all, 
is just a trivial case of the more general structure called a record, and a single record is just a 
trivial case of a more general structure called a file. 

To find the answer to some question that you believe can be answered by appeal to the data 
stored in a relational database, you specify — explicitly or implicitly — a series of one or more 
operations on one or more of the flat files in the database and get your answer, also, in the form 
of a flat file. These operations are part of something called "relational algebra" which has its 
roots in set theory mathematics. Some of these operations are exactly the set-oriented union, 
intersection, etc., that should be at least dimly familiar to you from your bygone New Math days. 

For many questions, the derived answer may wind up being a flat file containing just one record 
which might even have just one field. It is even possible that the answer file will turn out to be 
null — no records and no fields. But it will still be a flat file, even if a null or trivial one. 
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But file-at-a-time operations do not apply only for the purpose of querying a relational database. 
Add, delete and update versions of the same file-oriented operations used in query construction 
are also part of the relational picture. 

Relational Pedigree 

Before explaining just what these file-at-a-time operations are that I have repeatedly referred to, I 
want to use the idea of them to make a point about DBMS's generally. The DBMS on the AS/400 
— and on its direct predecessor, the System/38 — is unusual in that it constitutes the lowest-level 
file system that a user can access on these two machines. On most other computers, a DBMS is 
built either on top of, or alongside, some kind of ordinary file system, such as the one that SSP 
provides for the System/36. 

When a DBMS is just another piece of software on a system, there is not necessarily any way, in 
principle, to guarantee that the files it keeps can be accessed only by going through its interface. 
A relational DBMS that either implicitly or explicitly allows access to its files by means other 
than its formal, relationally algebraic operations cannot be purely relational. 

This point is relevant to the System/38 and AS/400 DBMS's for the following reason. While both 
have been called "relational" DBMS's, by the standard just advanced, they are not. Yes, the 
underlying physical files of both systems cannot have more than the single record format 
mandated by the relational model. But files maintained by both of these DBMS's can be accessed 
or modified — in familiar, record-at-a-time fashion — using RPG or COBOL programs exercising 
such operations as open, close, read next, read previous, delete and update. 

It is because the System/38 and AS/400 DBMS's are not implemented with relational, file-at-a- 
time operations as their lowest-level interfaces that they cannot be regarded as purely relational. 
In fact, none of the relational operations about to be discussed exist in any terribly obvious form 
via IBM-supplied software on the System/38. The AS/400, as of Release 1.2, has a subsetted 
implementation of SQL, which includes syntax for specifying most of the relational operations. 
Even here, though, the relational "coverage" is not entirely complete. 

New Math Revisited 

With the question of what "relational" means now clarified, it is time to turn to the question of 
what we might mean in talking about asking questions by operating on files and getting another 
file as an answer. Consider an example. Suppose your company conducts regular training classes 
of various kinds for its employees. Each class is offered four times per year and, for each class, a 
file is kept with records containing an employee name. 

Now suppose that it is necessary to send two people to a special outside class run by the vendor 
of a new robot system your company is planning to buy. The project leader wants to know, 
"Which of our people have taken the company courses on digital systems and hydraulics in the 
past year?" 

To answer this question, it would make sense to break it down into simpler sub-questions. One 
such sub-question is, "Which of our people have taken the company course on digital systems in 
the past year?" 
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To answer this derived question, it makes sense to combine the student files covering the last 
four sessions of the digital systems course into one file using the set operation called union. The 
union operation is analogous to the familiar Boolean operation called "inclusive OR" — if one or 
the other or both things are true, then the inclusive OR of them is true too. Similarly, if 
something is in one set or the other or both, then it is in the union of the sets too. Taking the 
union of four files at once just means that any record found in any of them will also be found in 
their union. 

Files From Files 

This union operation on four files to produce a fifth "answer file" — even if it is only an 
intermediate result — demonstrates a particular instance of the general approach embodied in 
relational database management of doing operations on files to produce another file that 
represents the answer to a question. 

Format Rules 

Of course in our example all the files to be combined with the union operation are known to have 
the same record format. You may legitimately wonder what the result is when a union is done on 
files with dissimilar formats. 

The answer is that the relational data model does not define meaningful results for the union 
operation unless all files participating do have identical record formats. The stricture that 
relational database files may have only a single record format takes precedence. 

Meet The Candidates 

Moving along, you can answer the sub-question, "Which of our people have taken the company 
course on hydraulics in the past year?" by creating a union of the last four hydraulics class files. 
Then, finally, you can answer the original question, "Which of our people have taken the 
company courses on digital systems and hydraulics in the past year?" by performing an 
intersection operation on the two class files that were assembled with unions. 

The intersection operation is analogous to the Boolean AND, which is only true if both of the 
things being ANDed are also true. In terms of the two unified class files, only names that appear 
in both will show up in the result. That result — the answer file for the question — will be a list of 
the names of every employee who has taken both of the desired courses within the past year. 

Get Real 

The basic concept of deriving an answer file by performing a sequence of suitable operations on 
one or more database files should be a bit more real to you now. But you may well feel that the 
example just offered still has its problems. You are right. If the statement of our problem, or the 
assumed file contents, had been a bit more "real world," the union and intersection operations 
would not have been capable of producing the answer we wanted. 

The most artificial condition was that the class files contain records consisting only of a name. 

As a practical matter, you can probably think of several more items of data that should be kept to 
properly record the history of in-house education courses. At a minimum, some kind of grade 
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value should accompany each name in the class records. 

But union and intersection, being purely set operations, treat files as sets and whole records as set 
members. Our example depended on the ability of an intersection operation to find common 
names in two files. The only way this can work is if the names are the only things in the file 
records. If grades were kept as an additional field in each record, then the last step of our 
example would not tell us the names of all people who took both courses within the past year, 
but only the names and grades of all people who both took the two courses and got the same 
grade on each within the past year — not the same question at all. 

If the relational data model idea of operating, conceptually, on whole files at once is to have any 
practicality, it obviously needs to include operations that can be sensitive to less than the entire 
contents of each record. Don't worry, such operations exist. 

Two More Ops 

Before exploring them, though, you should know that the formal definition of the relational 
algebra includes two other set-based operations that are like union and intersection in that they 
also treat whole files as sets and are not sensitive to the value of anything less than an entire 
record. 

The first is called difference. As its name implies, it is a sort of set-oriented subtraction. The 
difference of sets A and B is a set containing everything from A that is not also part of B. If A is 
the combined digital systems class file from our example, and B is the combined hydraulics class 
file, then the answer file, A - B, is the list of names of everyone who took digital systems, but not 
hydraulics during the past year. Just as with union and intersection, the definition of difference 
requires that the formats of the records in the operand files be the same for the operation to be 
meaningful. 

The last set-oriented relational algebra operation in the relational model is the Cartesian product 
or cross product. Unlike union, intersection and difference, a cross product can be done with files 
having dissimilar formats. 

The cross product of two files, A B, is a file whose members have a record format consisting of 
the format of file A concatenated to the format of file B. If file A's records have three fields and 
file B's records have five fields, for example, then A 

B's records will have eight fields each. The records in A 

B will be concatenations of every record of A with every record of B. The total number of 
records in A B will be equal to the product of the numbers of records in files A and B. 

More Ballast Over The Side 

As you might reasonably suppose, the degree to which the strictly set-oriented operations of the 
relational algebra are supported in implemented relational DBMS's varies considerably. Almost 
none, understandably, support cross product operations. DBMS designers have understandable 
nightmares about unwary users crossing a couple of 10-million record files. The lack is of almost 
totally academic interest only. I don't know how many of you have ever encountered a data 


Next 


Home 


Previous 








processing problem that could have benefited from generating a cross product of two files, but 
I've been in this business 19 years without meeting even one. 

The union, intersection and difference operations are much more easily implemented, but, as we 
have pointed out, they are also of rather limited use in solving realistic problems using well- 
designed files. Union is the easiest of the trio to implement and also, probably, the most likely to 
be of use. Not all allegedly relational DBMS implementations include explicit support for union 
operations, but many do. SQL, for example, has explicit syntax for specifying union operations. 
Explicit support for intersection and difference operations seems to be less widespread, 
especially as SQL provides only an implicit ability to specify them. 

Revised Example 

We come now to the three file-at-a-time operations that are central to the relational data model: 
select, project and join. To explain the essentials of each, let's first rework our example. 

One reason the union operation is of peripheral importance in relational DBMS implementations 
is that proper file design tends not to result in multiple files with the same format; what hasn't 
been sliced up doesn't need to be put back together. All those little class files should really just 
be groups of records in a unified file. 

Besides name or employee ID and grade, this file also needs fields for course ID and course date. 
We didn't say so, but in our original example the course and date information was probably 
coded into the file names of the many class files. The unique identifier key of the newly defined, 
unified employee training history file is a compound of employee ID, course ID and course date. 

With just one file in place of many, how can we go about getting an answer to our original 
question, "Which of our people have taken the company courses on digital systems and 
hydraulics in the past year?" We can start with the same strategy as before — chop the main 
question into several simpler questions, then answer these one at a time to arrive at the desired 
end result. 

Partials 

We can even use the same sub-questions. Let's start with, "Which of our people have taken the 
company course on digital systems in the past year?" Instead of putting a bunch of little files 
together to get the answer, we now must somehow pull the subset of appropriate records out of a 
single large file. 

The file subsetting operation of the relational algebra is select. To an old RPG programmer, the 
select operation is an old friend. In fact it is just a generalized version of what you do every time 
you code record selection criteria on an RPG input specification. Select allows you to specify a 
comparison test, or some Boolean combination of comparison tests, between desired values and 
specified fields of the records in the file. The result is an answer file with records having the 
same format as the original file, but containing — if you've specified the selection criteria 
properly — only a relative handful of records. In terms of set theory, you have specified a precise 
subset from a larger set. 

In the case of our example, you want all records in which the course ID equals "digital systems" 
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and the course date is not more than a year old. Given that there is no limit, in principle, to how 
complex or specific a set of select criteria can be, you might well want to restrict the selection 
still further and answer the question, "Which of our people have taken the company courses on 
digital systems and hydraulics in the past year and gotten a 3.5 grade or better on both?" Because 
of the limitations of the union and intersection operations, our earlier example, which relied on 
them exclusively, could not have provided an answer to this question. 

Adding the grade criteria to our sub-questions, we can answer the one that goes, "Which of our 
people have taken the company course on digital systems in the past year and gotten a 3.5 grade 
or better?" by specifying a select operation where course ID equals "digital systems", grade is 
greater than or equal to 3.5 and course date is no further back than one year. The corresponding 
sub-question about the hydraulics course is answerable with the same type of select operation. 
You just need to substitute a course ID criterion of "hydraulics" for one of "digital systems." 

Peeling Data 

You now have two small subsets of what we can assume is a sizable employee training history 
file. All we really want out of them, though, are the names of the people who took the courses. 
The subsetting select operation can be thought of as cutting out pieces of a file "horizontally" — 
the records selected have all the same fields as the ones passed up, there are just fewer of them. 

The relational project operation cuts the records in a file "vertically." Only some of the fields in 
projected records are pulled across to the answer file. The rest are left behind and discarded. 

In the case of the intermediate answer files for our two sub-questions, you only needed the 
course date, course ID and grade as selection criteria. Once the selection is done, the need to drag 
these fields along is finished also. By doing a project on both of these intermediate answer files, 
you can create a pair of successor answer files that contain just employee IDs. 

Homing In 

From the answer files of our two sub-questions, you are now ready to answer the original 
question. The way we have done things with select and project operations, the less powerful 
intersection operation could be used to get a final list of employee IDs of qualified employees in 
the same way it was done in our original example. 

You can also use the more powerful relational operation called join. The most common kind of 
join — and the only kind supported in many relational DBMS implementations — is the equi-join, 
in which records from two files are aligned and concatenated based on equal values of some field 
that is part of both their definitions. 

In the formal mathematical terms of the relational model, both record fields should be defined as 
having their values drawn from the same domain. As virtually none of the implemented 
relational DBMS's formalizes the idea of domain, however, joins are, as a practical matter, 
usually supported on field definitions of the same type and length. 

An equi-join operation is conceptually similar to zipping up a zipper, where the "teeth" of the 
zipper are corresponding values of the join field. The answer file of a join contains records with 
all the fields defined for both record types, but with the join field present only once, not twice. 
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The formats of the two files that participate in a join do not have to be identical. 

By joining our two intermediate answer files of employee IDs, the answer file will also contain 
employee IDs, but only those of employees who took both courses. The IDs of employees who 
took only one of the desired courses, but not the other, will not find matches across the two files 
and will not be part of the join. As a concession to the real world, in which the result probably 
ought to be names and not just ID numbers, you could do a second join of this answer file to an 
employee master file on the employee ID field, then do a project operation on that answer file to 
produce just a list of names. 

Joinery — Plain 

I described a join operation as being conceptually like a zipper that connects two files together. 

A more DP-related analogy that is often used is that of classical batch match/merge processing — 
something that is not exactly alien to the experience of veteran RPG programmers. 

But the match/merge analogy is not quite exact. When doing match/merge logic, for instance, a 
record from the primary file furnishes the field value that is compared to a field in a secondary 
file record. As long as each new secondary file record has a value that matches the primary file 
record's match field, the secondary file continues to be read from. When the secondary file yields 
up a record with a different value, the primary file is advanced until a new value is found for its 
match field. In general, if the primary file has more than one record with a given match field 
value, only the first of these actually controls the match/merge computations. The rest are, in 
essence, just shuffled through and bypassed. 

An equi-join, in contrast, treats those records that would be the second and subsequent matching 
primary file ones in a true match/merge, in the same way it treats the first record with a given 
join field value. When the two files being joined both have duplicated values in the join field 
column, the join is not a match/merge but is, instead, the union of a bunch of subset cross 
products. 

As an example, if file A has two records with a given join field value, and file B — which is 
being joined with file A — has three records with the same join field value, the answer file of the 
join will have six records containing that join value. The first three will be the concatenations of 
the first file A record with each of the three corresponding records from file B. The second three 
answer file records will be the concatenations of the second file A record with each of three 
corresponding records from file B. If a match/merge program could selectively and partially 
rewind its secondary file when more than one primary file record shared the same match field 
value, then it would behave like an equi-join. 

The most important consequence of this aspect of the definition of the equi-join operation is that, 
under suitable circumstances, it is perfectly possible for an equi-join answer file to have more 
records that either of the files that generated it. 

Joinery — Fancy 

Equi-joins are not the only kind allowed for by the relational algebra, however. A "greater-than" 
join, for instance, would have an answer table defined as the union of all subset cross products in 
which the join fields of records from file B had values greater than that of the join field in one or 
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a group of records from file A. 


Relational algebra allows for a join defined by any of the normal comparison operators: less- 
than, less-than-or-equal, equal, not-equal, greater-than-or-equal, greater-than. The answer tables 
for such non-equi-joins may not have as many records as a full cross product of two files, but 
they will tend to have enormously more than an equi-join of the same files on the same field. In 
the ordinary course of things, business DP finds little use for non-equi-joins. This fact, combined 
with the problems of implementing them, have led many relational DBMS implementers to leave 
out of their products any capability for producing non-equi-joins. 

Prime Mover 

As you should now appreciate, it is with the join operation that the relational data model answers 
our earlier rhetorical questions, "Where is the complexity? Where are the relationships?" In the 
relational view, relationships among records in multiple files are only potential when the files are 
defined. Actual relationships of interest to you are asserted dynamically by the act of specifying 
a join operation as part of a query or update process. 

The join operation is the central giver of meaning in the relational view of things. Select, project, 
union, intersection and the rest are just comparative "assistants," whose job is just to make sure 
that the really crucial work of joinery is conducted only on the record and field subsets that are 
genuinely germane. 

Not Quite Join 

Both the System/38 and AS/400 DBMS's support a thing called a join logical file as part of their 
basic capability. Join logical file is not equivalent to the relational algebraic join operation in 
many ways, the most important ones being that it is not dynamically specifiable and is based on 
equal values only. 

Wrap-up 

You should now have a useful grasp of what the relational database idea is all about, particularly 
the idea of operating on whole files at once to get answers that are, themselves, files. The 
treatment of this subject here has not been exhaustive, of course. We didn't, for instance, mention 
a relational operation called division, both because it is tricky to describe and because most 
relational DBMS's do not implement it directly. 

There is no question that the relational data model is powerful, elegant and even simple in many 
ways. But it is not without its warts. In the next installment of this series, you will learn about 
some selected non-relational ideas and of the ways in which both relational ideas and 
implementations fall short of perfection. 

Dick Eagleson, CDP is a freelance writer and systems consultant in Hollywood, CA. 
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As you start converting your System/36 procedures to AS/400 CL (Control Language) programs, 
you may find that some of the simplest things cause the most difficulty. Although there are a lot 
of similarities between OCL and CL, there is a lot more to learn about CL. The struggle to learn 
is richly rewarded, though, since mastering AS/400 CL gives you a tremendous amount of 
control over the operation, configuration and programming of the machine. 

In this article, we look at some techniques that you can use to "prompt" within your CL 
programs. This is compared with S/36 equivalents. Also, other areas of interest are pointed out so 
that you can investigate further. 

Why Are Simple Things So Difficult? 

One of the questions many new AS/400 programmers have is, why is this machine so 
complicated? Compared to the S/36, the AS/400 takes much longer to learn to use. One area 
which initially seems much more complicated is prompting from within what used to be a 
procedure. By looking at examples of how prompting can be done, and by further study of the 
commands used, you will see the AS/400 equivalents and discover some more powerful and 
useful options. Some things are more difficult on the AS/400 for the simple reason that you have 
more options. 

A Look at Some Examples 

The accompanying Figures 1 and 2 are meant as examples only. It is unlikely that you would 
ever produce a program exactly like this; in fact, there are a number of improvements that can be 
made. However, the example illustrates the following techniques: 

using a prompt format 
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You can also issue prompts from within an RPG program, or other HLL program, by displaying 
and reading a format. In some cases (such as illustrated here) you may find it easier to prompt 
from within a CL program, such as when you want to perform edits that can only be performed 
with CL commands. 

This article proceeds a bit differently from others, in that we review the concepts first, then go 
back through some of the specifics and explanations of the commands used. 

What the Example Program Does 

In the accompanying example, a display file is used as a prompt screen. The prompt is for a file 
and library name. The prompt is shown to the user (statement 6). The user can cancel the 
program by pressing Cmd3 (statement 10). 

The library is checked to determine if it is on the system. If it is, the file is checked to determine 
if it is within the specified library (statements 12-20). If the file or library is not found, the 
program redisplays the prompt format with error messages (statement 22). 

Next, if the library and file test is passed, a message is sent to the display, prompting the user to 
enter a selection for a command (statements 24-25). If the user selects the "D" option, the 
DSPFD (Display File Description) command is executed, using the library and file names 
specified on the prompt format (statements 27-30). If the "F" option is selected, the DSPFFD 
(Display File Field Description) command is executed (statements 32-36). 

Again, this is a "contrived" example, and is not meant to be particularly useful. However, it 
illustrates several techniques with only a few commands. You should experiment with the 
commands and options to construct programs that are useful in your particular situation. 

Prompting With a Display File 

Using a display file within a CF program is about as simple as using a //PROMPT statement in 
S/36 OCF. The only practical difference is that the display file must be declared in the CF 
program. In the illustrative program, line4 is used to "declare", or define, the display file to the 
CF program. When you compile the CF program, the program extracts indicator and field 
definitions from the file (this implies that display files used as prompts in CF programs must be 
(l)externally defined and (2)created prior to compiling the CF program). 

In the program, line6 is used to display and read the prompt screen. When you use the 
SNDRCVF (Send and Receive File) command, the screen is displayed with the initial values of 
fields or indicators. So, if you want to set fields or indicators to certain values before the display, 
you would do that in statements preceding the SNDRCVF command. This would be similar to 
setting S/36 positional parameters prior to a PROMPT statement. 

The SNDRCVF command is similar to the RPG/400 EXFMT (Execute Format) opcode. That is, 
when your program executes the command, the prompt screen is displayed and the program 
waits for a user response before proceeding. You can also use the SNDF (Send File) command, 
followed by the RCVF (Receive File) commands to accomplish the same thing. Those 
commands are similar to the RPG/400 WRITE and READ opcodes. I suppose you could use the 
SNDF/RCVF commands. In practice, I haven't seen any examples of SNDF/RCVF used for 
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prompting. You will use RCVF, though, when you want to read a database file within a CL 
program, but that's a subject for another article. 

One use for the SNDF command is when you want to display an "informational" or status screen. 
Typically, this would be something like the screen that S/36 SEU uses to tell you that the 
member is being loaded to the work space. For this usage, you neither expect nor require an 
operator input. You should use the LOCK keyword on the display file DDS so that the Input 
Inhibited condition will be in effect when the format is displayed. 

As a final note on the SNDRCVF command, you should know that there is a parameter available 
(RCDFMT) that is the equivalent of the FORMAT parameter on the S/36 PROMPT OCL 
statement. You don't need to use the RCDFMT parameter unless you have more than one format 
in the display file. If you do have more than one format, you will probably want to limit your CL 
program's "knowledge" of the additional formats by using the RCDLMT parameter on the DCLL 
command used to define the display file. 

Using Lields and Indicators With a Display Lile Prompt 

When you declare a display file to your CL program and compile the program, the fields and 
indicators defined for the format(s) become known to the program. Indicators are known as 
"&INxx", where "xx" represents the indicator number. Lields are preceded by the "&" character. 
The CL compiler defines the field type and field length for Input/Output fields in your display 
file. You cannot use DCL statements to define these fields and indicators. 

Lor example, statements? and8 in the example program use indicators 31 and 32. These 
statements are the equivalent of SETOL statements in RPG. Since the program uses indicators 31 
and 32 to signal error conditions, these are set off after displaying the screen, similar to what is 
done in RPG. 

The "editing" that is done is shown in statements 12through 20. To be brief, the first edit 
(statements 12-14) verifies that the library name exists on the system. If it does not exist, 
indicator 32 is set on. The second edit (statements 16-20) is executed only if the library name is 
valid; this edit checks for the file within the library. If the file is not found, indicator 31 is set on. 

If either edit fails, the program branches back to the SNDRCVL statement. Since one of the 
indicators is on, the field in error is displayed in reverse image, the cursor is positioned to the 
field, and an error message is displayed. 

This part of the program is repeated until Cmd3 is pressed to quit the program, or until valid 
values are entered in both fields. 

This example shows a situation where an edit must be done that is best accomplished with CL 
commands. That is, if you used an RPG program to process this prompt screen, you would have 
to CALL a CL program to check for the object's existence. On the other hand, if you need to do 
an edit such as determining if a certain record is in a file, you would want to do this within RPG. 

If you have a "mixed" situation, where you need to check for a record within a file, and you need 
to verify the file's existence also, you would probably use an RPG program that CALL'S a CL 
program for the file existence part of the check. 

You will have to work with CL for a while to become familiar with the types of edits that can be 
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done within CL. Generally, "system type" tasks, similar to the IF conditions that can be checked 
in OCL, are checked with CL commands. Edits pertaining to records in the database will 
probably have to be accomplished with RPG or equivalent HLL programs. 

Prompting With Messages 

Sending prompt messages can range from the very simple to the quite complex. In this article, 
we look at a simple equivalent of the S/36 "//*..." type of message, with the "?R?" parameters to 
retrieve values. Since this construct accomplishes the same functions as the OCL equivalents, the 
same common-sense rules go into its usage. That is, if you have a lot of messages, you should 
probably write a prompt screen. Also, you should restrict the use of program messages to system 
operators and programmers, since "normal" users tend to panic when they see the AS/400 
message display. They quickly come to associate the line across the screen with program errors. 
The mental association is similar to getting messages with option 2 or 3 on the S/36). 

The easiest type of program message that you can send is shown in statements 24-25. In these 
statements, we 

tell the program the text to display 
define valid values for responses 

tell the program to get a response (accepting the default of translating lower case to upper case) 
capture the response so that we can use it 

When this command is executed, the program sends a message to your terminal and waits for a 
response. They can only enter a letter "D" or "F" (in lower or upper case), or use Cmd3 or 
Cmdl2 to cancel the program. If anything other than D, F, or the commands is entered, the 
AS/400 sends a message and redisplays the message line. As a matter of style, you should 
probably always display valid entries in the message text, so that the user will have a clue as to 
what should be entered. Again, these types of messages are ki nd of an assault on the senses, and 
probably have already acquired bad connotations with the usual user. This type of prompting is 
not so bad when you need to send messages to a system operator type, or when you are making 
your own utility programs. If you do plan to make use of this technique for user prompts, you 
should probably get into the habit of entering "second level text" along with the message. This is 
the additional explanation that is shown if the HEFP key is pressed when the message is 
displayed. The second level text can be quite lengthy, and usually includes an explanation of the 
consequences of each option. You can see many examples of this with the IBM supplied 
messages. 

The whole point of prompting with a message is to return some value to your program, so that 
you can test it and take appropriate action. In the example, the value that is entered is available in 
the variable "&MSGDTA", which has to be declared to the program (in statement 3). Because 
the SNDUSRMSG command enforces the values that can be entered, you only have to account 
for those values in your program. 

Using Commands — System and User Supplied 
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This article reviews prompting with system supplied commands, although you can certainly 
create your own commands. As an aside, I will register my opinion that you should not be 
cluttering your system with commands that, essentially, are just renames of system supplied 
commands. For example, most people will, at some point, write a DQ command (or some 
variation thereof) which will have a command processing program to WRKOUTQ*ALL (display 
all output queues). For some reason, this has never sat right with me; maybe I am kind of cranky 
about this, but I feel that commands should be reserved for something a bit more useful than 
simply renaming other commands or demonstrating that you can write a command with no 
parameters. 

Which does bring up a point — when would you write a command, instead of just a program? I 
guess it is a matter of style and direction. You should realize, however, that to write an effective 
command you will need to code the command definition, a command processing program, and 
probably a "validity checker", which is used to check the values you enter for command 
parameters. Also, you should try to adhere to the AS/400 parameter naming conventions when 
creating your own parameters (for example, use the abbreviation LIB for "library", not LBY). In 
most cases, you can more easily write a CL program that accepts parameters, and do the validity 
checking within that program. 

On the plus side, the command prompter provides quite good screen formatting, and takes care 
of the situation where you have to enter lists, certain types of values, and more values than fit on 
one screen. You can probably do as well with prompt formats of your own design. Still, you may 
want to, and should, create commands that are useful in your situation. Just consider the pros and 
cons of commands over programs before you begin, and you'll probably do all right. 

Prompting With Commands 

Regardless of the origin of a command (system or user), you can use the command prompting 
functions within a CL program. In the example program, statements 27-36 show some of the 
options you can use when prompting with commands. 

The examples show some techniques and problems that I did not recall until creating the 
example. In the first IF group, statements 28-29 illustrate a technique of prompting a command. 
In this case, the "command" that we are using is the "?" (the "huh?") command. The "huh" tells 
the program to display the DSPFD (Display File Description) command in prompt mode. This is 
quite similar to entering the command name on a menu or the command entry display, and 
pressing the Cmd4 (prompt) key. Of particular interest in this example is the treatment of the 
command parameters: what it boils down to is that you can "hardcode" some of the parameters 
so that the user of the program cannot change them when the command is prompted. You would 
use this technique when you know ahead of time what some of the parameters must be, but need 
to get user input for the others. By hardcoding, you prevent selecting options that you don't want 
used. This is kind of a compromise between giving no access to the command and giving full 
access. I will review the options a bit later in this article, and tell you where to go for more 
information. 

The second example, shown on lines 33-35, shows another way to get a CL program to prompt a 
command. This method looks more complicated, and it is, but it is also an example of how you 
can execute a command from an RPG or other HLL program. Looking at it backwards, the 
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statement that prompts the command is 35, the CALL QCMDEXC statement. Because the 
QCMDEXC parameters don't allow specification of variables in the parameter (in this case, the 
fields &LIBRARY and &FILNAM), we have to first create a character string variable containing 
the value of those variables. This is done with statements 33-34. The CHGVAR (Change 
Variable) is similar to RPG when you concatenate variables using a work array. I will explain the 
details of this statement a bit later. For now, the whole point of the CHGVAR is to create a 
character string (&CMD) that contains the prompt character (?), the command to prompt, the 
first parameter name, and the values for the first parameter. For example, if the value for 
&FIBRARY is QGPF and the value for &FIFNAM is QCFSRC, the resulting character string is 
7DSPFFD FIFE(QGPF/QCFSRC). That character string can be used with the QCMDEXC 
program as the first parameter. 

As I mentioned above, this is the format that you use to execute a command from within an RPG 
program. For example, if you wanted to execute the command string composed above from 
RPG, you would code: 

(first create string) 

Z-ADD35 LEN 

CALL 'QCMDEXC' 

PARM CMD 

PARM LEN 

Which should you use in a CL program? Generally, most people are not aware of the "huh?" (?) 
command, shown in statement 28, so using it will probably create some confusion for whoever 
reads and maintains your program. The second form is more bothersome but more likely to be 
known, so you might want to adopt that as your convention. The second form, however, becomes 
more complex if you are entering defaults and conditions for many parameters, since you have to 
concatenate a great many string pieces. If you start creating complex strings, do remember that 
you can create pieces of strings, and then concatenate those together; you don't have to do it all 
in one command as shown in statements 33-34. 

Reviewing the Statements 

Now let's go over some of the options used in the sample program. This review will add to your 
knowledge of the options, and will help you get started on using these commands in your 
programs. 

To begin, the CL program should start with the PGM statement, although this is not required if 
you are not passing parameters to the program. You can also use a "label" on the PGM 
statement; I use the name of the program as the label. If you do want to pass parameters to the 
program, you identify them on the PGM statement and declare them with DCL statements. 

All DCL (Declare) statements must precede any executable statements in your program. You 
will find it helpful to "pretty print" the declares, by aligning the keywords over each other. It isn't 
much bother with the full screen editor, and it really helps when you proofread the program. 

Also, since CL programs can become quite complex and use many variables, you should 
alphabetize them or group them in some fashion. You can use up to 10 characters in the variable 
name, not counting the required preceding "&", and you can also use lower case letters and the 
(underline) character. So, you can be a bit more descriptive than in RPG. 

As shown in the sample program, you can use the DCLF (Declare File) command to tell the CL 
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program that you want to use a display or database file. Somewhat annoyingly, you are only 
allowed to declare one file per CL program. This can be a problem when you want to use a 
prompt screen and a database file in the same program. You get around this by having your CL 
program call another CL program. If you are using a display file for prompt screens, and have a 
number of formats in the display file, you will probably want to limit the formats used in the 
program with the RCDFMT parameter on the DCLF statement. You can specify up to 50 record 
formats to use in your program. There is no real harm in compiling the CL program and letting it 
compile in all of the record formats; it just makes somewhat of a mess of your compiled listing, 
and probably takes up some more space for no real purpose. However, it will create a compile 
error if you use the same field name in different formats, and the attributes of the field are 
different. 

Note that any indicators that you define are included in the CL program as "&INxx" fields. In the 
example shown, the PROMPT display file uses Cmd3 and associates indicator 03 with the 
command key. The CL program knows this as &IN03. Indicators 31 and 32 are treated similarly. 

You can set a command key indicator on by pressing it. This is done by using the SNDRCVF 
command, then testing for that indicator on statement 10. Note that the "condition" tested is 
simply "&IN03"; you do not have to code the condition as IF COND(&IN03='l'), since the value 
of a conditional statement resolves to a 'O' or T anyway. Again, this is ki nd of a shortcut that 
might confuse some readers of your programs, so you should code whatever feels right to you. 

Statements 12-14 and 17-19 illustrate a technique of checking for errors within a CL program. In 
this case, we want to check for the existence of objects, so we use the CHKOBJ (Check Object) 
command. With this command (and most other CL commands), error conditions are signaled by 
the command issuing one of many predefined system messages. The messages that are sent from 
a command, and can be "monitored" in your programs, are listed in Appendix E of 
Programming: Control Language Reference, Volume 1 (SC21-9775). Some commands can 
produce dozens of different messages. In the example program, the CHKOBJ command can 
issue any one of seven messages. For this example, we are not interested in any specific 
message, just the fact that a message was sent, indicating an error. You can "monitor" for 
"generic" messages by doing what the example program shows: monitoring for message 
CPF0000 tells the CL program that conditions are not what we would like them to be. 

To handle the error condition, you use the EXEC parameter of the Monitor Message 
(MONMSG) command. In this case, we want to EXEC (execute) a command to set on an 
indicator. If you need to do more complicated error processing, you can either EXEC a GOTO to 
a block of CL code that will perform the commands you need, or you can code an EXEC(DO) 
block. A DO block is terminated by an ENDDO statement. For the purposes of the MONMSG 
command, the DO block is considered to be "one statement", since that is all that the MONMSG 
command expects in the EXEC parameter. 

Statement 16 shows how to code a "N32" condition (and you thought you could get away from 
indicators). For more complicated logic, you can use parentheses to group conditions and then 
*NOT the whole thing if you need to. Remember, no matter how complicated the IF condition is 
(and you can create some real winners with CL), it all comes down to a 'O' or T value. Also, you 
should use continuation lines and indentation in your CL programs to make your logical 
conditions as clear as possible. When you enter CL statements using SEU, the prompter does a 
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pretty good job of continuing long statements, but you should feel free to touch it up where 
needed. 

Another logical statement, statement 22, is an example of a simple logical OR. 

Although not mentioned in the article, there are other SNDMSG commands that you might use in 
CL programs. You should probably investigate the SNDPGMMSG (Send Program Message) and 
RCVMSG (Receive Message) commands. These allow you to specify many more options than 
the SNDUSRMSG (Send User Message) command. The SNDUSRMSG isacombination of the 
SNDPGMMSG/RCVMSG command, and seems to be optimal for our purposes as a simple 
replacement for S/36 type prompting messages. However, as you create more complex AS/400 
applications, you will probably need to use the more powerful commands to get some of the 
effects that you want. 

Statements 33-34 illustrate some of the character string operations that you can use. You will 
quickly discover that character string operations in CL are much easier than in RPG. In fact, you 
might want to create a character string processing program that you can call from RPG programs. 
For example, CL supports three types of concatenation and the substring function; using those, 
you can create routines to center, right justify and create new character strings. The operations 
you can use are in Appendix B of the Control Language Reference, Volume I. As an aside, you 
should note that the concatenation operations can be referenced with symbols (i.e., "II" for *CAT, 
"I" for *BCAT, "k" for *TCAT). I sincerely think that you should avoid using the symbols, since 
most people cannot remember what they mean and some types of printers might not be able to 
print the characters. This also applies to relational operators. For example, use "*GE", not "=". 

Reviewing Command Prompting Options 

The command prompting options, shown in statements 28-29 and 33-34, are shown in chapter 6 
of the CL Programmer's Guide, SC21-8077. Use of the QCMDEXC program is also described in 
that chapter. 

The explanations given there are fairly easy to follow; the points to remember are that you can: 

1) 

supply default values for commands that you prompt within CL, 

2 ) 

display a default but not allow any changes while prompting, and 

3) 

supply a default and not display the parameter while prompting. 

When to use these options is entirely dependent upon the circumstances. It seems, though, that 
"naive" users are generally not as comfortable with using command prompt screens as they are 
with prompt screens that you create. This may be because you cannot control a command prompt 
screen quite as well as your own screen, so the types of error processing and helps that you can 
provide might be more limited. The AS/400 has taken some big steps in making these screens 
easier for casual users, but you should ask yourself: would I use the equivalent screen in my S/36 
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applications? For example, do you present users with the BLDINDEX or BLDFILE displays, or 
do you present your own prompt screen and take the values into procedures? You will have to 
find your own way with this, since it is not a matter of "right or wrong", but a matter of style. It 
seems that you should generally prevent users from using IBM supplied system-type commands, 
since those have the potential for creating the most havoc if used carelessly or ignorantly. 

Notes About the Display Format 

The display format example shown is rather simple, but illustrates several points that you should 
be aware of. For example, all of the fields and indicators are defined with TEXT fields. This is 
done so that any programs that use this format will include these descriptions as part of the 
compiled listing. 

As shown in the example, field names can be longer than six characters, although you should 
keep them at six or less if you will be using the format in an RPG program. You can also specify 
rudimentary validity checking as part of the display file definition. For both fields (FILNAM and 
LIBRARY), any entries in those fields must be valid names (CHECK(VN)), a valid name being 
a field that starts with a letter, includes only letters, numbers and a few special characters, etc. 

You would usually check for valid names when you use fields that refer to AS/400 objects. 

Also, field FILNAM can be accepted if we enter blanks (allow blanks, CHECK(AB)). We have 
not specified AB for field LIBRARY. The practical consequences of this are, if we enter an 
invalid field name in LIBRARY, press ENTER, get an error message, then try to use FIELD 
EXIT to enter a blank field, the system also signals that as an error. For FILNAM, we could 
enter an invalid name, then erase it with FIELD EXIT; the system would let that pass. This is 
useful if you want to give your users an easy way out: if they make an error and erase the field, 
they can then press Cmd3 to quit the program, if you specify CHECK(AB). 

Error messages can be associated with fields, and are displayed when the format is displayed 
with the indicator set on. These types of error messages require the user to press the RESET key 
before continuing. 

Now What Do We Do? 

Admittedly, this article has covered a lot of territory. That is one of the problems with CL — you 
ki nd of have to get into it all at once to get anything done beyond the simplest of tasks. However, 
even though it looks formidable in the beginning, it helps if you remember that you can take it 
one statement at a time. You should make liberal use of source formatting techniques for your 
CL programs and include comment and blank lines to separate sections of code. Also, I think that 
you should always use the command prompter in SEU to fill in the keyword names. That is, 
instead of entering: 

CHGVAR &IN31 'O' 

you can key the command in the SEU statement and press F4 to have the prompter help you 
complete the command. The result would be: 

CHGVAR VAR(&IN31) + 

VALUE('0') 

Why do that? Well, it ensures that positional parameters are in the right place, and it helps you 
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when you read the program. It's OK to enter commands without the keywords interactively, but 
in compiled programs and listings, you will find it easier if you "spell it out". Because CL is 
compiled, there is absolutely no execution time penalty in terms of speed, so forget about foolish 
"efficiency" arguments. 

Also, as you start to learn CL, you really should have the set of manuals at your desk. If you 
don't feel completely comfortable with a command, stop and look it up as you are entering the 
commands. The explanations of the parameters generally only make sense in context, and 
context is what you provide as you write and test your programs. 

Craig Pelkie works for Bits & Bytes Programming, Inc. in San Mateo, California. He always has 
the manuals close by. 
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Figure 1 CL program to test prompting 

Program TESTCL 


1 

TESTCL: PGM 



2 

DCL 

VAR(&CMD ) TYPE(*CHAR) LEN(35) 

3 

DCL 

VAR(&MSGDTA) TYPE(*CHAR) LEN(l) 

4 

c; 

DCLF 

FILE(DSPROMPT) 

D 

6 

READ: SNDRCVF 



1 

CHGVAR 

VAR(&IN31) VALUE('O') 

8 

Q 

CHGVAR 

VAR(&IN32) VALUE('O') 

10 

IF 

COND(&IN03) THEN(RETURN) 

li 




12 

CHKOBJ 

OBJ(QSYS/&LIBRARY) OBJTYPE(*LIB) 

13 

MONMSG 

MSGID(CPF0000) EXEC(CHGVAR VAR(&IN32) + 

14 



VALUE ( ' 1 ' ) ) 

15 




16 

IF 


COND(*NOT &IN32) THEN(DO) 

17 


CHKOBJ 

OBJ(&LIBRARY/&FILNAM) OBJTYPE(*FILE) 

18 


MONMSG 

MSGID(CPF0000) EXEC(CHGVAR VAR(&IN31) + 

19 



VALUE('1')) 

20 

ENDDO 



21 




22 

IF 


COND(&IN31 *OR &IN32) THEN(GOTO CMDLBL(READ)) 

23 




24 

SNDUSRMSG 

MSG('Enter D for DSPFD, F for DSPFFD') + 

25 



VALUES('D' 'F') MSGTYPE(*INQ) MSGRPY(&MSGDTA) 

26 




27 

IF 


COND(&MSGDTA *EQ 'D') THEN(DO) 

28 


9 

DSPFD ??FILE(&LIBRARY/&FILNAM) + 

29 



7-TYPE(*MBRLIST) ?*FILEATR(*PF) 

30 

ENDDO 



31 




32 

IF 


COND(&MSGDTA *EQ 'F') THEN(DO) 

33 


CHGVAR 

VAR(&CMD) VALUE('7DSPFD FILE(' *CAT &LIBRARY+ 

34 



*TCAT '/' *CAT &FILNAM *TCAT ’)') 

35 


CALL 

PGM(QCMDEXC) PARM(&CMD 35) 

36 

ENDDO 



37 




38 

ENDPGM 
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Figure 2 Display file DSPROMPT for test program 


Display file DSPROMPT 

A R PROMPT 

A 
A 
A 

A 5 

A FILNAM 10 B 5 

A 

A 31 

A 7 

A LIBRARY 10 B 7 

A 

A 32 


TEXT('PROMPT FORMAT') 

CFO3 (03 'CANCEL REQUEST') 
INDTXT(31 'ERROR - FILE NAME') 
INDTXT(32 'ERROR - LIBRARY') 

10 'ENTER FILE NAME:' 

35 TEXT('FILE NAME') 

CHECK(VN AB) 

ERRMSG('FILE NOT FOUND') 

10 'ENTER LIBRARY NAME:' 

35 TEXT('LIBRARY NAME') 

CHECK(VN) 

ERRMSG('LIBRARY NOT FOUND') 
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From Joe Davidson: 

While converting MAPICS I from the S/36 to the AS/400 a time savings was found worth 
passing on. 

The first step to the conversion is running a set of IBM programs to de-install several modules of 
MAPICS I. This worked great. Then, the conversion programs are run on both the S/36 and the 
AS/400. At this point we ran a print analysis on the S/36 that told us we would need 215 
diskettes for the conversion. Out of the question! 

I researched the S/36 conversion procedures and found that it was doing a transfer instead of a 
save. I changed the procedure to do a save onto tape instead of diskette. Three tapes later we 
were ready to load onto the AS/400. 

Since the AS/400 was looking to the diskette drive for the files, some changes were needed to the 
CL programs for the conversion to work using the files from a library on the AS/400. 

First the conversion CL programs were changed to read from the MAPICS36 library. Using the 
RESTORE command, we restored the S/36 files to that library. The Rename Member Name 
(RNMM) command was then necessary to get the member name the same as the file name (the 
RESTORE S/36 File command names the member name the same as the file date). The 
conversion menu options were then run to complete the process. This took eight hours to 
complete without any operator intervention. 

We believe that by making these changes we saved 40 or more man hours of diskette handling 
from one machine to another. Since we first used test files for the conversion, we will again see 
the saving of time when the live data is transferred. 
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From DataNetwork: 

The Attention key on the AS/400 does not function the same as it does on the System/36. Instead 
of presenting an Inquiry Options menu, it simply interrupts the current program and loads a user 
specified Attention key handling program. (The closest thing to the System/36 Inquiry Options 
menu on the AS/400 is the System Request menu presented when the System Request key is 
used). Many new AS/400 users have probably noticed that the Attention key doesn't do anything 
when it is pressed. This is because no Attention key handling program has been specified. You 
can use the Set Attention Program (SETATNPGM) command with the SET(*ON) parameter 
specified to identify a program as the Attention key handling program. Generally, if the attention 
key is pressed and the keyboard is unlocked for input (input inhibited light is off), the current job 
is interrupted, the display is saved, and the Attention key handling program is immediately 
loaded. (See the Work Management Guide and the Control Language Reference manuals for 
exceptions to this general rule.) No parameters are passed to the Attention key handling program 
when it is called. 

Because the Attention key is only acknowledged when the keyboard is unlocked, it would not be 
practical to use it with programs that keep the keyboard locked for any length of time (eg. a 
program that sequentially reads records from a large file). Using the Attention key with 
interactive programs can be a very good way of allowing an operator to access an often needed 
program on demand. For example, an operator that performs order entry throughout the day also 
needs to be able to answer questions about customer accounts. By specifying the customer 
account inquiry program as the Attention key handling program, the operator can call the inquiry 
program while orders are being entered by simply pressing the Attention key. When the inquiry 
program is exited, the order entry program will re-appear at the point it was left. 

The Attention key handling program runs in the same job and has the same job attributes, 
overrides, and group authorities as the program that issued the SETATNPGM command. 
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The Attention key handling program assigned by the SETATNPGM command will become 
effective at the current call level as well as deeper call levels and will remain in effect until the 
user signs off or another SETATNPGM command is issued. If the program that issued the 
SETATNPGM command returns, the Attention key handling program and Attention key status 
are reset to what they were before the current call. If a Transfer Control (TRFCTL) command is 
used, the status is not reset until the program that was transferred to returns. 

You may also specify an Attention key handling program in the user profile so that every time a 
user signs on, the Attention key handling program specified in the profile is available by way of 
the Attention key. 
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From: M. D. of Van Nuys, CA To: All 

Last week we did a crash recovery experiment with our AS/400. We fired up a number of 
apphcations then flipped off the power to simulate a blackout with jobs active. We wanted to get 
an idea of the length of an IPL after such an occurrence. We had heard a lot of horror stories 
about the time needed to rebuild access paths causing IPLs on the AS/400 to take as long as S/38 
crash recovery IPLs (longest heard was 72 hrs in Rochester lab environment). Well, to make a 
short story long, we lost a 9332 DASD during this test. It turns out that with the AS/400 crashes 
aren't handled as gracefully as the S/36. One CE said that you could lose hardware 1 out of every 
5 crashes. Luckily the DST tools enable you to do some pretty slick work with pumping DASD 
data to tape to avoid complete re-install of data from backups. Needless to say UPS's would be 
highly advisable with AS/400s in poor power areas. Good Luck!! 
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From: K. C. of Chestnut Hill, MA To: All 

Recently, I have started to define my files externally using DDS. After I compile the member, I 
store it in QDDSSRC in my library. I then rewrote an RPGII program to conform with RPG/400. 

I compile it and store it in QRPGSRC in my library. But at the bottom of my compile I get 
QRG2120 Severity 40 - External description not found for file specified as externally described. 
Also, QRG4118 Severity 40 - Externally described file name is invalid as a record format name. 
Also, QRG6100 Severity 40 - The record format name is missing and the file uses externally 
described data. Lines ignored to next valid type. In the IBM reference manual, I find no help or 
solution to my problem. It looks like (according to their examples) I am coding everything 
correctly, but obviously with my error messages, I am doing something wrong. Any help with 
this problem would be appreciated. 

From: C. R. of Las Vegas, NV To: K. C. of Chestnut Hill, MA 

In case you haven't solved it all yet, the reason that you are getting the file not found errors is 
because the file is in QS36F, and you are in your programming library. From what I can tell, you 
should be able to cure that by making sure that QS36F is on your library list. This did not work 
for me, but I think that might be a result of some other problems on my system. 

If it does not cure it for you, just CHGCURLIB QS36F and compile the program by typing 14 
and pressing F4 to get the prompt and then changing the object library to your program library. 

Let me know if adding QS36F to your library list cures it. 

From: G. W. of Coachella, CA To: K. C. of Chestnut Hill, MA 

I'm not quite sure what you mean "compile the member" in reference to DDS specs, but after you 
write the DDS specs and save them in QDDSSRC, you have to create a file from them with the 
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CRTPF or CRTLF commands. The native RPG compiler looks for the file, so it must be on your 
library list. PDM does not do an implicit SLIB the way POP did, so you can be working in a 
library with PDM and not only not have it be the current library, it may not even be on your 
LIBL. Since a lot of OS/400 commands default to placing things and looking for things in either 
*CURLIB or *LIBL, it pays to know what is on your LIBL and what your current library is. You 
can see your LIBL with DSPLIBL and change it with ADDLIBLE, CHGLIBL, and 
CHGCURLIB. Most of our early "not found" errors were related to LIBL problems. 


Next 


Home 


Previous 









MIDRANGE 

COMPUTING 

HR PUBLICATIONS INC. 


BBS: DDS Specs Problem 
April, 1989 

Copyright 1989, Midrange Computing 


by Openbbs Contributor 

Selected from DataNetwork's electronic bulletin board, TELEFORUM 
From: A. T. of Spotswood, NJ To: All 

I defined a physical file with DDS, ran the CRTPF command and everything went OK. Then I 
defined a Logical file with DDS, with 8 key fields. When I run CRTLF, everything goes OK. 
Problem is when I compile my RPG/400 program, I get an error that the key fields are not the 
same length. The RPG compiler is showing a key field length of 8. That is the length of the first 
field only. Is there anything I am doing wrong? For instance, do I have to put a '+' on the line or 
something? Possibly, I have to concatenate the fields? This is my first externally described file. 

From: C. P. of San Mateo, CA To: A. T. of Spotswood, NJ 

Art, when you defined the logical, you put a "K" in front of each field name that is a key field, 
right? For example, 

R LOGFMT PFILE(PHYFILE) 

K KFLD1 
K KFLD2 
K KFLD3 

and so on. Assuming you did that,the compiler will pull in that definition. Check to see if you 
have a duplicate object (file) somewhere else in the system that has a different key definition. 

The compiler finds file definitions based upon the library list in use during the compile 
(remembering that your interactive library list can be different from a batch library list). 

From: A. T. of Spotswood, NJTo: C. P. of San Mateo, CA 

I did define the K next to each record for my key fields as you said. The only thing I did different 
than your example (which may be because you're saving space). I redefined every field from the 
Physical file in the Logical file DDS. For example: 
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FIELD3 
K FIELD3 
K FIELD2 


Should I be putting every field in the logical file that I want to access, or just the record format 
name? 

One last question: Can I externally describe a file in library XX, and have programs in library 
XX that use the file as program-described? I want to keep programs that are not yet re-written in 
the same library the new and shiny RPG/400 programs. 

From: C. P. of San Mateo, CA To: A. T. of Spotswood, NJ 

You don't have to redefine the fields in the logical. When you use the PFILE statement, it will 
include all of the fields from the physical file. 

On the other hand, if you want to limit the fields that are in the logical file, you would then list 
just the fields that you want. I saw this in an IBM article long ago, their example showed how 
you could give someone access to a file but protect some of the fields (for example, a payroll 
master file, but not allow access to pay rate or some such). I can't recall ever using a logical file 
that way, but you can if you need to. 

You can access an externally defined file as an "old style", if you code the F-spec with a record 
length. You would then need I-specs also. I am fuzzy on this, but I don't think you need the exact 
record length, I think it can be greater or equal to actual record length, which you can determine 
with the DSPFD or DSPFFD command. Also, since I've not done this, I doubt that you can chain 
to the file using an externally defined key. 

I still don't know why your program compiled with the wrong key fields, but check on the 
compiled listing amongst the F-specs, and see where the compiler got the file definition from. 
That is, the compiled listing shows you the actual library that the compiler used for the file. 
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I am trying to estimate the time it will take to migrate from a S/36 to an AS/400. Does anyone 
have some actual estimates ... such as 2 hours/program, etc. The estimate should be all inclusive 
(planning, migrating, implementing, etc.). 

From: R. L. of MT Kisco, NY To: M. B. of Morristown, NJ 

It all depends on the size of your S/36. How big is your system in terms of a) disk capacity, b) 
program libraries, c) actual program members? 

Based on the several migrations I've done so far, a mid-size S/36 in a "typical" shop should take 
2-3 weeks to do it right, longer if you do full acceptance testing on the AS/400. 

From: M. B. of Morristown, NJ To: R. L. of MT Kisco, NY 

We have a 5360 S/36 with 800MB of disk, 65% used for files & libraries. We also have 3 active 
communication lines to a dial-up mainframe(s) and another dedicated line to a mainframe. How 
much education is required before one can migrate & convert? 

From: R. L. of MT Kisco, NY To: M. B. of Morristown, NJ 

I'd say that the 2-3 weeks would be right for your installation. As far as education and training, if 
you plan on starting in the S/36 environment, you won't need too much up front. The on-line 
tutorial that comes with the system will familiarize you with basic concepts. It is very much on 
the light side for experienced programmers. The biggest immediate training curve you will 
experience will be for your operators. Controlling printers and other devices on the 400 is very 
different than on the 36. 
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Are you using MSRJE for comm to/from the mainframes? If so, the new RJE utility for the 400 
is also very different. I set one up recently. It was complicated (as you'd expect from IBM) but 
once it was in place, it seemed like a very nice package .... better than MSRJE on the 36. 

Hope this answers your questions. 

From: A. T. of Spotswood, NJ To: M. B. of Morristown, NJ 

I just converted a S/36 with 8 libraries and approximately 300 files to an AS/400 without any 
"formal" education. I asked quite a few questions on this board (thanks to everybody, by the 
way). What I am saying is that the AS/400 has great help screens, and if you are used to the type 
of screens used in Query/36 and Text Management, you could definitely migrate to the AS/400. 
Migration from the Sys/36 for me involved scanning all of my library members to make sure the 
subtypes were correct (i.e. RPG Source was RPG, DFU source was DFU, etc. The AS/400 uses 
these to compile them later). After all the subtypes were correct, I migrated one library at a time 
(you can do this while there are users on the Sys/36), and then put the tape into the AS/400, and 
wait. There are very few options you need to worry about to restore on th 00. There is one option 
to restore all items from tape or diskette. Pretty simple. 

If you are a programmer who knows his way around the Sys/36, try migrating without classes. 
The thing that gets you started is the Sys/36 environment. It is slower than native mode, but you 
can use D P for spool files, D U for jobs, etc. Figure out later what the Native commands are 
when you've got time?!? 
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We are an AS/400 (30) shop running in the S36 environment, and are planning to take our first 
stab at working with the database feature. I am planning to experiment using DDS. Since all our 
data files are in library QS36F, should all DDS specs be contained in file QDDSSRC within 
QS36F? Incidentally, are there any special parameters when building the following files 
QS36PRC,QS36RC,etc.? I would appreciate any comments. 

From: C. P. of San Mateo, CA To: J. L. of Los Angeles, CA 

To answer your questions backwards: 

1) Even though there are a lot of parameters on CRTSRCPF cmd, you really don't need any of 
them, other than source file name and library name. I also use TEXT. 

2) You can create the source file in QS36F, but you might want to locate the source file in the 
application library. For example, if you have a Payroll library, you might create a source file 
there, another for Accounts Receivable, etc. The main idea is that you remember where you put 
it, so try to make it easy. I guess I would not choose to put it in QS36F. Putting it elsewhere 
would kind of help you to mentally leave the nest. 

From: R. D. of Denver, CO To: J. F. of Eos Angeles, CA 

We are converting from a S/34 with lots of DFU's and just jumped into DDS. I would suggest 
creating DDS specs outside of QS36F so you can eventually get rid of it. We use a file called 
dictionary to describe control fields which are referenced in the individual file DDS. This helps 
with standardization and reduces keying in edit codes and headings. (You can rename a field by 
referencing another field with the REFFFD keyword and make modifications to it at the same 
time.) 
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Be careful when you compile (create) the new file. The old file with its data is deleted every time 
you compile. You need to copy data back to the new object with the CPYF command. 

Your 36 environment defines what library 36 jobs go to for files and programs, if its not there, 
then the library list is searched, so once you have defined your files in your new library, remove 
it from QS36F. 
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Has anybody found a way to restart a printout on a certain page? I can't get STRPRTWTR to 
work correctly. 

From: J. L. of Los Angeles, CA To: A. T. of Spotswood, NJ 

I too would like to know how to restart a printout from a certain page. However, our system 
operator has come up with a way; she merely pulls the forms out of the printer after which the 
AS/400 will prompt you to either cancel the print or start from a certain page. Unorthodox, but it 
works. Hopefully we'll get time to go through the manuals and figure it out. 

From: A. T. of Spotswood, NJ To: J. L. of Los Angeles, CA 

I have used that method myself. There was a really funny reaction on the office girls' faces when 
I told them to rip the paper out of the printer. Again, my software guy said the STRPRTWTR 
should do it. It does have a keyword for page number, but I can't get it to work. 

From: C. P. of San Mateo, CA To: J. L. of Los Angeles, CA 

I never thought of pulling the paper out, but the STRPRTWTR with a page number should work 
if you use CNLWTR (Cancel Writer) first. Kind of hazy on this one, but I know I've done that in 
the past. 

From: D. D. of Tacoma, WA To: J. L. of Los Angeles, CA 

There is no restart spool writer on the AS/400. But you can accomplish the same thing in a round 
about way. First, HLDWRTWRT(writer ID). Then, after the system finishes holding the print 
writer, enter: RLSWRT WRT(writer ID) PAGE(page#). I have written a command and CL 
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program to do this but it is a little involved to explain here. 
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We rejoin our safari in progress, stalking the wily database in the jungle where the jargon gets 
thickest. 

Recap 

Our last episode was devoted mostly to explaining what a relational database system is and some 
of the reasons why the AS/400's DBMS, nice as it is in many ways, is not really relational. A 
relational database, recall, is one in which the basic unit of data manipulation is a whole file. File 
operands are operated upon by operators drawn from something called the relational algebra, 
which, itself, draws heavily on the mathematics of sets in its underpinnings. 

While directly comparable set-oriented operations like union and intersection are part of the 
relational algebra, the really critical such operations are: select, which creates subsets of the 
records in a file; project, which creates records having a subset of the fields defined for a file; 
and join, which generates a new file by zipping together pieces of records taken from two 
existing files. 

Recall also that, while file joins can be done based on any ki nd of inequality comparison, the 
most useful — and by far the most commonly used — join is the equi-join in which records from 
one file are deemed to be relatable to records in a second file if both records have the same value 
in a designated field in each. 

Nulls On Parade 

As it turns out, there is a bit more to the joining business than we had space to cover last month. 
To understand why, we have to bring back to center stage our old friend from two installments 
ago, the null. A null, remember, is a field marker that denotes a missing or unknown value, as 
distinct from a known value of numeric zero or alphanumeric blank. Support for null values is a 
feature of many DBMS's, including a number of relational ones. 
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Now the thing about nulls is that they introduce some ambiguity into the definition of a join. 
Consider a first case. File A is joined to file B. Some of the records in file A have null values in 
the join field, but no records from file B do. By the rules of the equi-join, none of the file A 
records with a null join field value will wind up represented in the result file. 

An exactly analogous thing happens if it is file B that has some records with null join fields and 
file A whose records have none. In this latter case, it will be the file B records with the null join 
field values that get shut out of the result file. 

Nulltiplication 

This isn't necessarily bad. In most cases, it is probably even what the database user has in mind. 
But what about the case where both file A and file B have some records with null join field 
values? 

By strict application of our equi-join description, the result file should include, in addition to 
records derived from equal non-null values, an additional group of records representing the 
subset cross product of all the file A records having a null join field with all the file B records 
traveling similarly light. If file A had two such records, for instance, and file B had three, the 
result file would have six. It is by no means obvious that this sort of result is what a database 
user would necessarily have in mind when commanding a join of files A and B. 

There is also no way — by straight application of the rules for equi-join we have explained so far 
— to specify other possibly desirable results. For instance — to return for a moment to the case 
where file A may have some null join field values but file B does not — how can we require that 
all file A records having a null join field value are to be carried over to the result file, one for 
one, with additional null values slugged into these result file fields where the field values of a file 
B record would have gone if there had been any that matched? 

The Outsiders 

Some relational DBMS's provide one or more ways of specifying how cases involving null join 
field values are to be handled. A join whose definition is altered to provide suitably special 
handling of records with such nulls is called an outer join, perhaps because it causes certain 
records to be participants in the result file of the join instead of being consigned to the outer 
darkness. 

What Do You Do With A Null Field Value Ear-lie In The Morning? 

Truth to tell, not every relational database guru is happy with the mess that null handling makes 
of the otherwise nice, clean definitions of the relational algebraic operations. For this reason, 
some such folks have urged that support for null value tokens be stricken from the list of 
supported features in relational databases. 

I'm sure you can appreciate the desire for tidiness that motivates this position. But you should 
also realize that the information conferred by the presence of a null value - as opposed to any 
zero, blank, non-zero or non-blank value — is legitimately useful on those systems that support 
null values. 


Next 


Home 


Previous 








The modest degree of inelegance that partial or comprehensive null handling imposes on 
relational DBMS's should be seen, then, as just one of those places where the relational model of 
data doesn't quite cover the entire waterfront. 

Look Ahead 

The subject of null values is maybe not too interesting to AS/400 shops that already have, or will 
write, all of their own applications. The AS/400 database, after all, doesn't support null value 
tokens and neither does the subset AS/400 version of Structured Query Language (SQL) that is 
now available. Why even know anything about nulls at all then? 

The answer is only potential at this point, but it is also likely. There are relational DBMS's that 
do support nulls and more full-blooded versions of SQL that let you work with them. The much 
wider choice of programming languages offered by the AS/400, as compared to its predecessor 
System/36 and System/38 machines, makes it probable that the idea will occasionally come up of 
porting "SQL-based" code onto the AS/400 from its current resident hardware platforms. More 
than one of you out there reading this will, at some point in your careers, probably be called on 
to do some of said porting yourselves. 

But not all SQL is created equal, so to speak. There are significant variations in the basic syntax 
supported by the numerous "dialects" of SQL — especially the PC-based ones. But trying to 
make SQL-based applications written for an environment with null value support work on the 
AS/400 is going to be messy at best and impossible at worst. The semantic gap between null 
value support and no null value support is enormously greater than any minor problems of 
syntax. 

Climbing The Walls Over Climbing Trees 

The question of nulls or not is bad enough, but there is another, generally more serious, semantic 
shortcoming of the relational data model. It provides no really organic way to represent and 
handle any data file whose records are supposed to have hierarchical relationships among 
themselves. 

Unfortunately, in the real world, certain entities are most naturally represented as a genuine 
hierarchy of records with a single one defining a top level in the hierarchy and all the others 
being, logically, a part of some subsidiary level in the hierarchy. Common examples are 
organization charts, family trees, and bill-of-material definitions for manufactured goods. 

The T.O. (Table of Organization) example is a useful model. It is possible to define a single 
record format containing two fields drawn from the domain EMPLOYEE ID. One such field, 
which keys the record, identifies the employee to whom the rest of the data in the record refers. 
The other such field — which we can call WORKS FOR — contains the EMPLOYEE ID of the 
person's boss. 

In so-called hierarchical or "network"-type databases, there would actually be some kind of 
explicit linkage defined to hook all records for his or her subordinates to the record of each 
superior. Such loops or chains of pointers would be as many layers deep as the number of layers 
of management in the company. 
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Other Paths Than Codd's 


To further define these perhaps unfamiliar concepts, the effective difference between hierarchical 
and network DBMS's, in fact, is that a hierarchical database often supports participation in only a 
single hierarchy for any given record. Network DBMS's tend to allow any given record to belong 
to any number of defined hierarchies. In some hierarchies, the record may be top dog. In others, 
it may be part of the lowest stratum or from anywhere in between. The interlocking nature of 
many such relationships — each of which is logically a hierarchy — is, indeed, a "network," hence 
the name. 

Accessing such databases is usually done with record-at-a-time commands, many of which are 
"navigational" in nature; they pick records to read by following those bound-in relationship 
pointers already mentioned. 

Indeterminate Sentence 

The relational data model has a problem with such inherently hierarchical intra-file record 
relationships. The relational algebra allows a file to be joined to a second copy of itself, of 
course. You could start defining a hierarchy of rank with a relational DBMS by joining the 
WORKS FOR field of the file to the EMPLOYEE ID field of the second copy of that file. 

But doing so wouldn't, in the general case, yield an answer file that represented the complete 
hierarchy. To accomplish that, you would have to do repeated join operations hooking the 
"rightmost" set of WORKS FOR fields to the EMPLOYEE ID field of yet another copy of the 
original file. 

In a system with support for null values, the first such join would have to be an outer join or the 
CEO's name wouldn't wind up in the result file. The person at the apex of the hierarchy, of 
course, would have a legitimately null value in the WORKS FOR field of his or her file record. 

Even if you ignore the one pesky null in this picture, though, the catch is, you can't know, in 
general, just how deeply layered the hierarchy represented by any such file is. Therefore, if you 
are to use a non-procedural, just-declare-your-intentions language such as SQL to manipulate an 
implicitly hierarchical file, you can't specify any fixed number of join operations and still be sure 
you can always materialize the complete hierarchy represented by any arbitrarily structured such 
file. Hierarchies seem inclined to cling stubbornly to a need for manipulation only by iterative or 
recursive — but procedural, algorithmic and record-at-a-time approaches. 

The moral of this tree tale for any AS/400 programmer is that, while you may be able to use SQL 
code to fetch individual records in a file with an implicitly hierarchical structure, you will not get 
help from SQL at any level more complex than this if bill-of-material processing, or any other 
intrinsically hierarchical processing, is on the to-do list. 

Binds That Tie 

The concept of binding is one that has a lot of application to the field of database management. 
To bind something is to tie it down — render it inflexible. In many important ways, for instance, 
the effective difference between relational DBMS's and hierarchical or network DBMS's is a 
matter of what they choose to bind and when. 
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Hierarchical and network databases, for instance, take a tack on defining and binding inter¬ 
record relationships that is the polar opposite of the relational approach. Each hierarchy in a 
hierarchical or network database represents some "owner/owned," "superior/inferior," or other 
"pecking order"-type relationship between records in different files or the same file. 

In addition to the unavoidable need to name files and define their component fields, one at a 
time, such systems usually require you to declare and define each hierarchical relationship type 
in advance of need. In fact, the typical hierarchical or network database is defined in terms of a 
data definition language (DDL) that is then compiled to produce an executable "kernel" for the 
DBMS. 

With this compile first/use later approach, there is no way to dynamically create fields, files, or 
record relationships with such systems. This "cast it in concrete" approach to binding database 
definitions is exactly analogous to sysgening an operating system or defining an interactive 
terminal environment using some inflexible, last generation tool like the CCP monitor on the old 
System/3 Model 15's. 

Hanging Loose 

Now compare the usual relational approach. It is still necessary to define files in terms of fields, 
but most relational systems allow you to do so on-line and incrementally. As for relationships, 
these are the essence of spontaneity. Relationships between the records of two different files, or 
between the records of a file and a second copy of itself, are asserted by the simple expedient of 
doing a join operation on the two. 

Similar contrasts surround the ways in which databases can be accessed. The typical hierarchical 
or network DBMS can be communicated with only via record-at-a-time commands compiled 
into, and issued from within, programs written in some fairly ordinary programming language. 

Relational DBMS's, on the other hand, are usually designed for interactivity. Their usual mode of 
accepting commands is via an interactive interpreter for SQL or some equivalent query language. 

Making A Pass 

It is possible with many relational DBMS's, to also issue commands from inside programs 
written in conventional computer languages. This is handled via a language preprocessor that 
reads an otherwise ordinary program containing embedded statements in, say SQL. The 
preprocessor pass generates statements in the appropriate programming language to reserve 
suitable data areas and issue the subroutine calls needed to attach the DBMS, access the database 
and pass data back and forth between the database and the working storage of the program. 

If such a program needs to preserve great flexibility, in terms of what commands are issued from 
call to call, most such systems allow a program to feed a full-text query string to the DBMS, just 
as if it was a human operator at an interactive terminal. Lor queries or commands that are more 
cut and dried, the preprocessor can sometimes partially or fully "compile" embedded database 
language statements for greater speed of execution. Thus, relational DBMS's that include 
embedded query language preprocessors, tend to offer more than one choice as to the binding of 
queries and accesses. This will be true, in particular, of the AS/400's SQL implementation. 
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All Together, Now 


The file-at-a-time operations of the relational algebra are easy enough to understand, but they are 
not so easy to implement. Conceptually, relational algebra operations are performed all at once in 
a blinding flash. The big limiting factor is that a real computer cannot actually do any operation 
that involves more than one file record in a way that is truly "simultaneous." This is very much 
the case, certainly, for operations such as join which often involve large numbers of record 
accesses to complete. 

A Foolish Inconsistency 

This inability to perform relational algebra operations that are truly simultaneous in all their 
effects is a subset of the more general problem that it is also impossible to achieve physical 
simultaneity of effect for any arbitrary group of two or more relational algebra operations. 

Why should this be important? Because, even if the relational model of data does not 
acknowledge the existence of ongoing, semantically significant relationships among the fields of 
certain combinations of record types, they still exist. Where such a relationship exists, allowing 
one record in such a related set to get "out of sync" with its fellows compromises the integrity 
and usefulness of the data in a real way. 

Sync Check 

The obvious example is one of those situations where you have decided to keep a frequently 
referenced total or subtotal in each record of a given file, while the contents of a field in the 
records of a second file constitute the detail items that should still add up to equal the totals in 
the first file. 

Suppose file one is an invoice master file and file two is an invoice detail file. If an adjustment 
needs to be made to one of the line item quantities, a simultaneous adjustment of exactly the 
same magnitude needs to be made to the corresponding total or subtotal kept in one of the master 
file records. 

Holding Pattern 

Since this is physically impossible to do, some form of "reservation" or "embargo" needs to be 
placed on access to whichever of these two records is changed first, and lifted only when the 
second of them has also been brought back into balance with the first. 

This problem of temporary, but perhaps critical, imbalance when updating related items in more 
than one record is not a problem that is unique to relational DBMS's, or even to DBMS's at all. 

The same problem can afflict applications written with absolutely familiar file system services 
such as those on the System/36. 

Because this problem of maintaining synchronization is especially tricky for operations 
involving potentially hundreds or thousands of records — relational algebra operations, in other 
words — relational DBMS's tend to have particularly robust cures implemented. 

The details of approach vary a bit, but the general scheme is to acquire, and place logical update 
locks on, every record that needs to appear to be modified simultaneously to maintain a 
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consistent state for the database. The record updates can then be performed serially, but none of 
the locked records is released until all updating is complete. 

Trans Bracket 

In the context of SQL — whether used interactively or via embedding in a compiled program — 
the language allows you to declare BEGIN TRANSACTION, then execute or submit one or 
more commands that reduce to relational algebra operations on database files, and finally, 
declare END TRANSACTION. All record modification activity commanded between the 
transaction "brackets" will be done using whatever locking protocol is employed to keep any of 
the changed records from being accessed until all are consistently updated. 

Who's On First? 

In last month's installment, you were run through some query scenarios that described how the 
questions might have been answered by applying successive operations of the relational algebra 
to the files. In truth, it is unusual to find a query statement that can be solved only one way by 
application of a single relational algebra operation. Most real queries cannot be satisfied unless 
two or more — perhaps many more — relational algebra operations are applied against the 
affected files. 

Whenever there is more than one of something, of course, the question always comes up of 
which one to do first. It turns out that even after translating a SQL, or other query language 
command, into its component relational algebra operations, the problem of deciding in what 
order to apply them is quite difficult. 

Cheat Sheet 

To provide themselves with as much advantage as possible in attacking such problems, relational 
DBMS's always include a query optimizer component. The query optimizer, in turn, relies on 
special files that summarize the data content of the rest of the files. Some systems even make 
these special files readable by ordinary users as part of the system data dictionary. 

The query optimizer knows, for example, which fields of which files have indexes established on 
them. It may also keep small summaries of those indexes — every thousandth value, say, or ten 
values selected at evenly spaced intervals along the index, including the highest and lowest 
values. Sophisticated query optimizers might keep additional data about the data — a count of 
how many different values are represented in a given field across all records in a file, for 
instance. 

Order Matters 

How good the query optimizer is in a relational DBMS has a very non-trivial affect on real-time 
performance. Consider the example of a 10 million record file which contains a first name and a 
code for male or female among other items. Suppose the query is for all males with a first name 
of Tammy. This factors into two select operations, one to look for first names of Tammy and the 
other to look for a sex code of 'M.' But which should be done first? 

A query optimizer that kept statistics on the number of unique values represented in a file, per 
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field, would note that the sex code only had a value of two. It would know that it should expect 
roughly five million records to contain each of the two values. Doing a first select that will yield 
five million records is probably not the sharp way to go. Especially if the whole file has to be 
traversed to pick them out. This would probably be necessary as no one with sense would index a 
field with only two possible values in a 10 million record file. 

The optimizer would then look at the first name field and find that it was indexed and had 10,000 
different values represented. The optimizer would know that it could look 'Tammy' up directly 
using the index. It would also know that, if the distribution of names was absolutely random out 
of that list of 10,000, that there would be roughly 1,000 Tammies. 

The choice becomes clear. First, use the index and sift out the Tammies. Then sift through the 
Tammy records to see if any of them has a sex code of 'M.' An especially astute optimizer would 
probably contrive to test the sex code as each 'Tammy' was found and not even bother writing to 
a work file if the code was 'F.' 

To Be Continued 

IBM now offers AS/400 SQF, so the question of how good the product's query optimizer is will 
have real urgency for users. We can't answer that yet, but we hope to have something intelligent 
to say on the matter in a future installment. You'll know just as soon as we do. 

In the meantime, be sure to come back next month for a look around the basic AS/400 database 
management system. It ain't quite relational, but it ain't bad. 
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by Richard Shaler 

IBM has given AS/400 users more than 80 Free utilities 

Release 1.2 of IBM's AS/400 contains a surprise, the QUSRTOOL library, which contains more 
than 80 useful application development and system management tools. 

To name a few, it contains a program that scans source members within all source files in a 
library, a print program that produces a generalized printout of any externally described file, and 
a program that will save only changed objects within a library. 

Most of the programs can be used as they are, though many people might want to customize 
some code to suit their needs. That will not be a problem because all source code is included. 
Programmers who do not need any of the tools can still benefit by studying source code and 
applying the techniques to their own programs. 

A complete overview of the tools can be found in source member AAAMAP of file QATTINFO 
in the QUSRTOOL library. 

The Tools 

The tools are divided into six major categories: 

PC Support Configuration Tools 

Provides commands that allow the programmer to create PC Support users and configure the 
different attachment environments (Twinax, Token-Ring, and SDLC). 

Graphic Tools (Compatible with AS/400 GDDM) 

Provides commands that allow conversion of pictures and images to image graphic file formats 
compatible with the AS/400 GDDM. 
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Manage Work Management Configuration Facility 

Provides a menu-driven-and-display-interface to the system work management facilities. 

Storage Space Management Tool 

Facility to help automate procedures to manage auxiliary storage. 

Example Communication Configurations 

Display interface which allows one to create example configuration objects for particular 
communications configurations. 

Programming and System Management Tips and Techniques 

Collection of functions which can be used to implement common programming requirements and 
functions to manage the system. 

Figure 1 shows that each category has a two-character identifier, a primary documentation 
member within file QATTINFO, and source for an install program within file QATTCL. 
Explained later is the exception that the installation member CRTTAATOOL must be created 
(don't ask us why!). Installation instructions for each section are different, but are documented. 
We will go through the installation steps for the Programming Tips and Techniques section to 
provide a glimpse of what is involved. The majority of tools are found in that section. To create 
the tools for any of the other five sections, refer to the documentation member for that section. 

Installing the Programming Tips and Techniques Tools 

QUSRTOOL is shipped with the operating system, so you will not have to load it. If for some 
reason it is not on your system, it can be installed using "Option 7" of the base operating system. 

QUSRTOOL contains source members for the tools. It does not contain any of the tool's objects, 
nor is it intended to. They are placed in the TAATOOL library when they are created by the 
CRTTAATOOL command The TAATOOL library must be created as well as the 
CRTTAATOOL command. The steps necessary to accomplish this are listed in Ligure 2. 

The first command shown (CRTLIB) creates TAATOOL library. The second command 
(CRTCLPGM) creates program TAATOLAC which when called creates the CRTTAATOOL 
command. 

Once CRTTAATOOL has been created, you are ready to create the tools. Security officer 
authority is needed to run the CRTTAATOOL command. Since you can either create each tool 
individually or all at once, you may wish to create only specific ones. A one-line description of 
each tool, arranged by category, and a paragraph description by tool, can be found in source 
member TAASUMMARY in file QATTINLO. 

A user can expand on the one-line description by creating DSPTAATOOL, which will yield 
more information on all the other tools. This is created by running: 

CRTTAATOOL+ 

TOOL(DSPTAATOOL) 
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The command above that creates DSPTAATOOL provides an example of how to create a single 
tool. To create the tools all at once, run: 

CRTTAATOOL+ 

TOOL(*ALL) 

CRTFILLIB(library) 

where library is the library to contain data base files used by some of the tools. Creating all tools 
at once may take several hours to run, so consider submitting the job to batch. 

There is more detail on creating and using the CRTTAATOOL job in the source member 
CRTTAATOOL of file QATTINFO. 

Another utility that can be created to help in managing the tools is CPYTAATOOL. This will 
copy the tool's source members to a specified library. 

One last note on installation is that you must add TAATOOL to your library list before you can 
use any of the tools. 

Modifying Members 

QUSRTOOL contains all of the source code and documentation members in source files 
QATTINFO, QATTCL, QATTCMD, QATTDDS, QATTPL1, QATTRPG. To change any of the 
source members, first copy them to a user library. Do not leave any of the tools in place in 
library QUSRTOOL and modify them there, because when you update to future OS/400 releases 
you would overwrite them. 

All source members are prefixed with TAA and can be copied to the library of your choice with 
CPYTAATOOL. To find the names of the source members associated with a function, use 
command DSPTAATOOL to give detailed information on the tool and its TAA source members. 

At the top of this information, to the right of the title, is the prefix of all associated source 
members. 

This prefix can be used with the CPYTAATOOL command when copying members to another 
library for modification. The library that is to receive TAA members must contain source files 
QATTINFO, QATTCL, QATTCMD, QATTDDS, QATTPL1, and QATTRPG. 

Once modifications have been made, run CRTTAATOOL, specifying the user library containing 
the modified members. The objects will be placed in TAATOOL library. 

Managing Your Tools 

To avoid the chaos of having tools scattered throughout the system, a sensible approach to tool 
management is needed. Here are examples of the libraries that you could have on your system to 
handle all your programming and system management tools: 

QUSRTOOL 

All source code for base tools as received from IBM. 

OURTOOLS 

A library the user creates to contain modified source code copied from QUSRTOOL. This 
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library could also contain tools that you have created from scratch. In this case it would be your 
"all purpose tools" library. 

TAATOOL 

All objects associated with either the source code from QUSRTOOL or OURTOOLS. 

Examples of QUSRTOOL Tools 

The following is a partial list of some of the more powerful tools found in the Programming Tips 
and Techniques section: 

CHKDAT 

Validates a date field for range and year. 

CHKPSW 

Allows a user to change password, forces a change after X days, and checks the password against 
previously used ones, which are kept in masked form. 

CHKSAV 

Checks a single library or all libraries and compares the save date/time against the last date/time 
change for each object and member. 

CMPSRC 

Compares two source file members and prints a listing of the differences, noting added or deleted 
statements. 

CPYSPLTXT 

Copies a spool member to a source member. 

CRTPRTPGM 

Creates a generalized print program for an externally described file that can be used by the 
PRTDBF command to print a simple listing with optional control breaks, decimal field editing, 
adding numeric fields, etc. 

DLTDEPLGL 

Deletes dependent logicals. Operates on physical files, but does not delete the physical file. 

DSPDB 

Displays an externally described file by placing the field names and values for a single record on 
a display. Roll up and down are supported. 

EDTVAR 

Edits a decimal CL variable into a character field. 
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LOCKMSG 


Describes a standard method of producing a message on a locked record. Can be used to send a 
message to a user or system operator describing the locked record condition and allows optional 
replies. 

PMTOPR 

Prompts an interactive operator for a single value and provides error checking. Can eliminate CL 
validity coding when prompting for a single value. 

PRTSAVSTS 

Prints libraries, noting what medium was used for a save. This is useful for help with recovery 
when you must know which libraries were saved and on what medium they were saved. 

RSTANYLIB 

Restore any library. Allows the system operator to adopt the security officer's profile, avoiding 
not being properly authorized to all objects. 

RTVDAT 

Retrieves a specified date in a variety of formats such as the name of the day and month, week of 
the year, etc. 

SAVALLCHG 

Saves all the changed objects in user libraries on the system and provides a listing of what 
occurred. This might be an excellent supplement to a regularly scheduled SAVLIB *NONSYS. 

SAVWHLACT 

Save data base file while active. Requires that journaling be used. 

SCNALLSRC 

Allows one or more standard-named source files to be scanned for a character string. 
TIMDEPSCH 

Submits a job or sends a message to be executed at a later time in the current or future day. 
WRTSRC 

Writes or updates source statements from CL. Allows dynamic creation of source to be followed 
by a create step. 

Hope For the Future 

It is a good sign to see IBM giving us extras such as the QUSRTOOF library. They seem to have 
a renewed commitment to providing us with the technical assistance we need. Fet's hope it will 
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continue. 


Figure 1 QUSRTOOL categories and member names 
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PC Support Configuration Tools 

LC 

TLCINFO 

TLCINST 

Graphics Tools 

GR 

TGRINFO 

TGRINST 

Work Management Functions 

WM 

TWMINFO 

TWMINST 

Storage Space Management Tools 

SP 

TSPINFO 

TSPINST 

Sample Communications Configurations 

DC 

TDCINFO 

TDCINST 

Programming Tips and Techniques 

AA 

TAASUMMARY 

CRTTAATOOL 


* provides installation instructions 


Figure 2 Creating the CRTTAATOOL command 

Creating the CRTTAATOOL Command 

CRTLIB LIB(TAATOOL) 

CRTCLPGM PGM(TAATOOL/TAATOLAC) SRCFILE(QUSRTOOL/QATTCL) 

CALL PGM(TAATOOL//TAATOLAC) 
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A simple ORxx would make life so much easier 

The simple OR condition ... why is it such a problem on the System/36? Because IBM made it 
that way. 

System/36 programmers were excited when IBM brought RPGII more in line with other high 
level languages with the announcement of structured operation codes in Release 4.0. But as we 
have seen over and over again, something was left out. Although we were given the IFxx, 
DOWxx, and DOUxx operation codes, they are, in all practicality, useless for coding OR 
conditions. 


Let's take the example of having to compare a field named TYPE for any of three values — 'A', 
'B', or 'C'. To show why we are complaining, we'll first take a look at the preferred coding 
method with operations available on the S/38 and AS/400: 

TYPE IFEQ 'A' 

TYPE OREQ 'B' 

TYPE OREQ 'C' 

.... TYPE is 'A', 'B', or 'C' END 

See anything unfamiliar? If you have tried to use IFxx's for OR conditions before, you will 
immediately discover the operation that you have since longed for — the ORxx. With ORxx, you 
can very easily set up simple or complex OR situations by simply continuing any IFxx, DOUxx, 
DOWxx, ORxx and ANDxx with more conditions. 


Now that you know what we should have been given, let's look at the methods that we on the 
System/36 are resolved to using. For the sake of simplicity, all our examples will use the IFxx 
operation code, but relate as well to DOWxx and DOUxx. First of all, there is the COMP 
technique, the oldest, but still the easiest solution: 


50 


TYPE COMP 'A' 

N50 TYPE COMP 'B' 

50 ... TYPE is 'A', 'B', or 'C' 


50 

50 N50 TYPE COMP 'C' 
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Some programmers don't like coding in this manner because it uses the dreaded indicator. We 
have no problem with indicators when used properly, as in the above example. (See the 
September 1987 issue for our complete philosophy on indicators.) 

But for those of you who will avoid indicators at all costs, there are two more viable options. 

One of these is to create several single 'IF true' conditions, all performing the same operations: 

TYPE IFEQ 'A' 

. . . TYPE is 'A' 

END 

TYPE IFEQ 'B' 

. . . TYPE is 'B' 

END 

TYPE IFEQ 'C' 

... TYPE is 'C' 

END 

This does the job, but adds a lot of code, not to mention the redundant code it creates. But if you 
have only a few conditions to check, and the code that will be executed is short, then this 
technique isn't too bad. 

But if the code you will execute is lengthy, you are better off placing it in a subroutine and 
calling it. If this route is taken, the IFxx's could be replaced by the CASxx operation: 

CASEQ'A' SUBR 

CASEQ'B' SUBR 

CASEQ'C' SUBR 

END 

Our personal opinion at DataNetwork is that you should use the COMP method if you will not be 
executing many lines of code (for instance, if any of the conditions are met, perform an EXCPT). 
If you have much more to do, and it makes sense placing it all in a subroutine, then use the 
CASxx technique. We don't see any benefit in using the multiple 'IFxx' groups. 

There is no excuse for not including the ORxx operation along with the RPGII IFxx, DOWxx, 
and DOUxx operations. Surely, it was not an insurmountable technological feat, since RPG 
easily handles OR conditions with COMP. As with many other simple things that could have 
been and should have been on the System/36, they probably just held back to make the next 
generation of computer more desirable. 
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For all the wonders of the AS/400, there is no Printer Restart 

Last month in TeleForum Offline, there was some discussion on re-starting an AS/400 printout at 
a certain page. The problem is that there is no command for restarting a printer (unlike the 
System/36). The only way to do it is by ending or holding the writer, and then starting or 
releasing it from a certain page. A couple of TeleForum users had discovered the rather 
unorthodox solution of ripping the paper out of the printer, and waiting for the subsequent 
prompt to either cancel the print or start from a certain page. While it works, there is an easier 
solution. 

Rich Doonan replied in TeleForum that you could execute a HLDWRT WRT(writer ID) and 
then, after the system finished holding the print writer, execute a RLSWRT WRT(writer ID) 
PAGE(page#). To automate the process, he wrote a command and CL program to do it all and 
was ki nd enough to send it to us to share with everyone. 

Setting Up and Using RP 

The command and CL program, both called RP, are listed on the following page. Key the RP 
command (Figure 1) in source file QCMDSRC of a library and create it with the CRTCMD 
command. Key the RP CL program (Figure 2) in source file QCLSRC of the same library and 
compile it with the CRTCLPGM command. After they are created, make sure that the name of 
the library is on your library list. 

To use RP, just key RP and press F4. You will be prompted for the name of the print writer and 
the page number on which to restart. You can skip pressing F4 by keying the parameters on the 
command line. For example: RP PRT01 54 will restart printer PRT01 on page 54. Note that a 
user must have special authority *SPLCTL to run RP. 

The CL program first holds the print writer and waits until it is held. It then restarts the print 
writer at the line number you keyed. The default values are print writer PO and page number 1. 
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These can be changed in the RP command. 


Additional pages may be printed before the print writer is held since there is a delay from the 
time this program is executed and the printer responds. 

How it Works 

CL programming and command creation may be new to many of you so we offer the following 
explanation of RP. 

RP Command 

The PARM statements define parameters which will be passed to the CL program. These 
parameters enable the selected keywords (KWD) to be displayed as prompts for the user when 
F4 is pressed. The default value of each parameter is set by the "DFT" keyword. 

RP CL Program 

Statement 100: Begins the program and receives the two parameters passed to it. 

Statements 200-600: Declare the program variables. 

Statement 800: A global message monitor, which will cause the program to go to the command 
label ESCAPE if any error occurs which is not intercepted by a monitor message command 
following the command causing the error. It doesn't matter where in the program the 
unmonitored message occurs, this statement will catch it. This technique could be used in many 
CL programs that have the potential to create unmonitored messages. 

Statements 1000-1200: Holds the print writer but monitors to test if writer is already held 
(CPF3332) or is in the process of being held (CPF3334). In either case a skip is made to 
command label RETRY. 

Statement 1400: Causes the program to wait three seconds while the writer is being held. This 
can be changed to match the time it takes your system to hold the print writer. 

Statements 1600-2500: Causes the writer to be restarted at the selected page if the writer is 
presently held. If it is not held yet, the program goes to the command label RETRY. The first 
time the program encounters this error, it sends the user a message telling them to be sure the 
printer is running. If the printer is not turned on at the time the RP command is executed, the 
print writer will never be held and the program will go into an endless loop. The variable 
&ONCE is used as a flag to prevent the message from being issued more than once. 

Statement 2600: Causes the program to terminate and return to caller. 

In an interactive program, it is a good idea to build in an error routine to catch unmonitored 
errors (any error messages not monitored by the MONMSG command). The remaining 
statements make up this type of routine. 
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Statement 2900: Receives the error message id and data. 

Statements 3000-3100: Tests to see if an error message was received. 
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Statement 3200: Displays the error message received in statement 2900. 

Statement 3300: Branches back to command label ESCAPE to check for another error message. 

Statement 3500-4000: Causes any of the program's escape messages to be displayed, which 
otherwise might only be seen in the job log. 


Figure 1 Restart Printer command 

CMD PROMPT('Restart print writer') 


/*-*/ 

/* Associated PGM is RP */ 

/*-*/ 


PARM KWD(WRITER) TYPE(*CHAR) LEN(10) DFT(PO) + 

ALWUNPRT(*NO) ALWVAR(*NO) PROMPT('Print + 
writer:') 

PARM KWD(PAGE) TYPE(*CHAR) LEN(5) DFT(l) + 

ALWUNPRT(*NO) ALWVAR(*NO) PROMPT('Page # + 
to restart:') 


Figure 2 Restart Printer CL program 


RP: + 

PGM PARM(&WRITER &PAGE) 

DCL VAR(SMSGID) TYPE(*CHAR) LEN(7) 

DCL VAR(&MSGDTA) TYPE(*CHAR) LEN(132) 

DCL VAR(SWRITER) TYPE(*CHAR) LEN(10) 

DCL VAR(&PAGE) TYPE(*CHAR) LEN(5) 

DCL VAR(&ONCE) TYPE(*CHAR) LEN(1) VALUE('0') 

MONMSG MSGID(CPF0000) EXEC(GOTO CMDLBL(ESCAPE)) 

HLDWTR WTR(&WRITER) 

MONMSG MSGID(CPF3332 CPF3334) EXEC(GOTO CMDLBL(RETRY)) 
/* Wait until writer is held */ 

RETRY: + 


DLYJOB DLY(3) 

/* Restart writer at selected page */ 

RLSWTR WTR(SWRITER) PAGE(&PAGE) 

MONMSG MSGID(CPF3334) EXEC(DO) /* REPEAT UNTIL HLDWTR COMMAND + 
HAS COMPLETED. */ 

IF COND(&ONCE *EQ '0') THEN(DO) 

CHGVAR VAR(&ONCE) VALUE('1') 

SNDUSRMSG MSG('Be sure the printer is on at this time') + 
MSGTYPE(*INFO) 

ENDDO 

GOTO CMDLBL(RETRY) 

ENDDO 

RETURN 

/* Error trap for any other error */ 

ESCAPE: + 

RCVMSG MSGTYPE(*DIAG) MSGDTA(&MSGDTA) MSGID(&MSGID) 

IF COND(&MSGID *NE ' ') THEN(DO) /* IF ANY MESSAGES */ 

SNDPGMMSG MSGID(&MSGID) MSGF(QCPFMSG) MSGDTA(&MSGDTA) + 
MSGTYPE(*DIAG) 

GOTO CMDLBL(ESCAPE) 

ENDDO 

RCVMSG MSGTYPE (*EXCP) MSGDTA (&MSGDTA) MSGID (&MSGID) 

/* Receive the escape messages */ 

IF COND(&MSGID *NE ' ') THEN(DO) /* IF ANY ESCAPE MESSAGES */ 

SNDPGMMSG MSGID(&MSGID) MSGF(QCPFMSG) MSGDTA(&MSGDTA) + 
MSGTYPE(*ESCAPE) /* BUBBLE ESCAPE MESSAGE UP */ 

ENDDO 

ENDPGM 
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Those of you on the AS/400 have seen the QTEMP library, but do you know why it is there? It is 
designed to specifically contain objects that are only necessary for the duration of a job. In other 
words, if you have a job that creates a file that is deleted before the job terminates, it can be 
changed to create the file in QTEMP. The specific deletion of the file is no longer required — at 
the end of the job, the file is scratched. 

In addition to automatic deletion, any files in QTEMP only exist for their creating job. When 
using QTEMP, you don't need to worry about file name uniqueness among jobs. 

There is one thing to keep in mind if you plan on using the QTEMP library: The time between 
sign-on and sign-off is considered one job. If you run an interactive job that creates a file in 
QTEMP, it will be there until you sign off the session. While the "quasi-temporary" nature of 
QTEMP files in interactive jobs can sometimes be a limiting factor, the invisibility of the files to 
other jobs is still a great benefit. 

DataNetwork Staff 
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There may be times when you need to copy a source physical file (PF-SRC) to a data base file 
(PF-DTA), or vice-versa. For example, you might have a compile-time table in an RPG program 
that requires frequent maintenance. To alleviate the re-compiling step that follows each change, 
you decide to create a data file from the program's table. You could rekey each table entry into 
the file, but an easier method is to transfer the data from the source member to a data file. The 
solution is to use the CPYF command to copy a temporary source member containing only the 
program's table to a data base file. But, if you have never done this before, the format differences 
between a source physical file and a data file could cause you some problems. 

A source physical file is essentially the same as a data file, with the exception of the first twelve 
bytes in each record. These positions contain a six digit sequence number field and a six position 
date field, which are automatically maintained by Source Entry Utility (SEU). A source physical 
file normally has a record length of 92, but can be as short as 13 or as long as 32,766. 

To start, create a target data file using the CRTPF command. The record length must be 12 less 
than the source physical file (normally 80). Next, perform the copy with CPYF with *CVTSRC 
in the Record Format Field Mapping parameter. This will drop the sequence number and date 
information from the first 12 bytes of the source physical file record. All data in the target file is 
then shifted to the left by 12 positions. 

Conversely, you can add the 12 bytes of information when going the other direction by placing 
the proper values in the Record Format Field Mapping parameter and Source Options parameter 
of CPYF. Like the source file to data file copy, the Record Format Field Mapping parameter 
must contain *CVTSRC. But, an additional requirement is that the Source Options parameter 
contain the values *SEQNBR and *DATE. Be sure the target source file's record length is at 
least 12 bytes longer than that of the physical data file. 

DataNetwork Staff 
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Selected from DataNetwork's electronic bulletin board, TELEFORUM 
From: T. P. of New Orleans, LA To: All 

We are tentatively planning to go to the AS/400 next year. We're taking the attitude that we'll 
have to go to the AS/400 sometime anyway, so why not get it when it's fashionable (nice reason 
huh?). We think, but don't know for sure, that we will outgrow our current configuration about 
that time, which will coincide with higher maintenance costs and less support from IBM (still not 
very precise planning). I'd like some input from people with experience going from the S/36 to 
AS/400 about the benefits. From a system management and program development and 
maintenance standpoint, how "good" is the new box. Please consider the following: 

1) We plan to purchase an EDI system soon. 

2) We are about to rewrite the software for one side of our business. 

3) Our backup "system" is a nightmare (12 mags of files, 5 mags of libraries). 

4) Increased need for upload/download of data and terminal emulation. 

5) Our S/36 will be fully depreciated at the end of this year. 

Would we be better off getting the new box sooner? What are the economics? What should I 
figure into my cost/benefit analysis? 

From: C. R. of Las Vegas, NV To: T. P. of New Orleans, LA 

If you are planning a move to the AS/400 sometime in the future and you are planning to rewrite 
a heap of code soon, the time to upgrade is NOW! In our shop, which is very small, we have 
experienced tremendous programmer productivity gains on the AS/400. Literally we have 
doubled our output. We came over from a S/36 to a little (B20) AS/400. The debug facilities and 
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enhancements to SEU make the AS/400 about 3 or 4 times easier to work with. I used to use 
POP on the 36, but AS/400 SEU is MUCH better. I am sure that once we have approached the 
top of the learning curve our shop will see about a 200% gain in productivity. 

I have worked on S/36's from the time they were announced and S/34's before that. While I still 
consult on S/36's and I think they are wonderful machines, they are nothing next to the AS/400. 

Before your company (and you!) invests in rewriting code on a S/36, consider how much faster it 
(the development) will go on an AS/400. 

Keep in mind, before the AS/400 arrived here I had never seen one, nor a manual for it. Because 
my IR messed up we did not get our manuals until last week (we bought the system at the end of 
October). But I had almost 0 problems running the system. 

All this might sound like pie in the sky promises, but I mean it. 

From: T. M. of Hickory, NC To: All 

I have wanted an AS/400 since it was announced because of what IBM has told me it will do, 
and to stay current with technology. Right now it looks like it will be about a year before we get 
one, but I am beginning to have second thoughts. As I read this BBS, all I see are problems with 
migration, sorts, data and everything else. Some of the messages come from people who sound 
desperate! If this is what I have to go through, I don't know how I feel now. I can't afford to 
spend 6 months on conversion and then not get any new projects done because of trying to get 
old programs to work. Is it as bad as it sounds!!!!??????????????? 

From: C. P. of San Mateo, CA To: T. M. of Hickory, NC 

No, it is not as bad as it sounds. 

If you are still a year out, you are really in an ideal position. That is, you can start, NOW, to go 
through your current programs and applications, and really polish the code so that you know 
exactly what each program and procedure does, what the layout is for every data file, and so on. 

Most of the problems that you are hearing about are the result of trying to accomplish too much 
too soon. I don't know why it is, but whenever a new machine arrives anywhere, there is a 
sudden desperate atmosphere, like, WE HAVE TO GET THIS THING UP AND RUNNING BY 
NEXT WEEK! Supposedly, this is the result of management wanting to start getting their ROI 
AS API think you should begin educating your management as to what a conversion entails: it is 
a chance to get improvements all around, and it really can't be rushed. If you did conversions 
often, then you would know what to look for, where to take shortcuts, etc. However, this is 
probably the only conversion your company will undertake for at least another 5-8 years, so 
why try to rush everything into the first two or three months? Believe me, I have spent a lot of 
time going back through junk that was converted in a hurry, and bringing it up to snuff (I'm 
talking about S/38 conversions I've done, which entail the same considerations as the MOO ). 

If you are going to get the machine, order the manuals from IBM now. Get the RPG, DDS, any 
overview manuals, etc. That way, you can be following along with the articles in DN and this 
board. 
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If all of your programming has been on /36 type machines, you might consider getting RPG III 
from ASNA or RPGII 1/2 from BPS , since you have a year to get used to the concept of 
programs calling programs. It's about $1500. What's that you say? Your management doesn't 
want to spend money for something that you need to educate yourself to do the job required of 
you? That attitude, exactly, is why there are problems. Good computer systems, and people 
knowledgeable about them, are expensive, and niggling about $1500 is not exactly the smoothest 
route from point A to point B. 

My point is that there is a tremendous amount of work that you can be doing now that will help 
you avoid a tremendous amount of the "problems" that can happen. One year is just about the 
right amount of time to plan for conversion. Why don't you see if there are any sharp S/38 or 
AS/400 consultants in your area, that also know the S/36, and see if you can get them in for a 
couple of afternoons? Once or twice a month should be useful; go over some of your concerns 
with them. If you plan to do the conversion yourself, make that clear to them up front, and tell 
them that you're only hiring them for their advice. 

I've not meant to cast aspersions on any of the other fine people that write in with problems; it's 
just that I suspect they are the victims of too much work and too little time. You, however (and 
many others reading this), have time, so start making plans. 

The AS/400 is probably the best computer that IBM has ever produced, in any of their product 
lines. If your shop is truly a midrange environment, this is the machine you want to get. 

From: R. L. of Mt Kisco, NY To: C. P. of San Mateo, CA 

I concur! Thanks for a very nice analysis of what's going on. For those who do have to go 
through conversion, there's nothing like a formal written plan prepared in advance that covers all 
the bases and finds the problems beforehand. 

The three rules for a successful conversion are planning, planning and planning. (When you fail 
to plan, you plan to fail). I believe that with enough proper project management, you can get 
through a conversion reasonably quickly without surprises. 

From: C. P. of San Mateo, CA To: R. L. of Mt Kisco, NY 

Well, in MOST cases planning helps things go pretty smooth. 

I used to do a lot of work with a consulting organization, and we did about 20 conversions to the 
S/38. Looking back, I would say that one of the biggest problems and time-wasters was the DP 
staff and management insisting that everything be done exactly as on the old system. I'm not 
talking about changing the end results (i.e., what users used), but coding things to take advantage 
of the new machine. 

We had lots of fights with shops that were afraid of "converting to external files," not for any 
good reason, but just because they were afraid of the unknown. 

The other time-waster is trying to wade through old, bad programs and try to figure out what 
they're doing. That's why, if anybody has lots of time in advance of a conversion, I think they 
should take a few programs a day and clean them up. It's a monstrous job if done all at once, but 
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if little pieces are taken over time, it's hardly any effort. 

From: R. L. of Mt. Kisco, NY To: C. P. of San Mateo, CA 

You raise an excellent point, one that I've seen during the several S/36-AS/400 migrations I've 
helped with, that is that the customer expects the AS/400 to be a big, fast S/36. They want and 
expect EVERYTHING to work EXACTLY as it did on their S/36. 

In some respects, this is IBM's problem. They have been selling the S/36 Special Environment as 
a duplicate of the S/36 interface and it just isn't.... especially for the system operator. 

From: T. M. of Hickory, NC To: C. P. of San Mateo, CA 

I will have to admit that when the machine was announced, and even before then, I was ready to 
bring one in the first day. I am glad that we did not rush into it now because I would hate to be 
having all these problems. I think if I can get our project list slowed a little we will do as you say 
and dig in and clean up our system. This is usually not a pleasant experience but I would rather 
do it now than have some of the problems I've seen here. We are planing to use an outside 
company to help direct us. They have an AS/400 and seem to know what they are talking about. 

Thanks for the advice. It does make me feel a little more at ease about going ahead with things. 
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by Openbbs Contributor 

Selected from DataNetwork's electronic bulletin board, TELEFORUM 
From: S. K. of Woodbury, NY To: All 

One of the many parameters in the CHGUSRPRF (change user profile) command is one to set 
and enable an Attention key program. 

An Attention key program is one that runs when the Attention key has been pressed. This should 
be a CLP or RPG program. It can be any type of program that can be called using the CALL 
command. 

For the Attention key program parameter I use QCMD in library QSYS which is the AS/400 
command entry display. Thus, whatever program I am in, I can interrupt it and get a command 
display by a single press of the Attention key. This sure beats having to do the Shift-SysReq-1 
sequence to get an alternate session. 

As with any changes to a user profile, the user must sign off and then sign back on for the change 
to take effect. 
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by Openbbs Contributor 

Selected from DataNetwork's electronic bulletin board, TELEFORUM 
From: S. K. of Woodbury, NY To: All 

A problem exists in the AS/400 S/36 environment. Specifically, when using native commands in 
an OCL36 procedure, execution of the procedure continues to the end despite the fact that any or 
all of the embedded native 400 commands ended in error. The effect can be likened to use of 
NOHALT and auto response on the System 36. The only clue that an error occurred is contained 
in the joblog for the job in question. 

A call to IBM Level 2 elicited the answer that the above is not a problem, but a normal execution 
time "feature" of the 36 environment. That is the way it works and the NOHALT effect cannot 
be turned off. I explained to him that an important restore had seemed successful (no error 
messages to the screen), but in fact, only after checking the joblog (and the fact that nothing was 
restored due to authorization problems) did I learn that something was wrong. Also, a file 
reorganization routine had failed at a critical point. Again, I did not find out until later that I had 
been burned. 

A circumvention as suggested by Level 2 is to use the message i.d. substitution parameter 
7MSGID? after every embedded native 400 command in an OCL36 procedure. This parameter 
will be null if the command executed successfully. It will contain the CPF error message if it was 
not successfully completed. I have been using something like the code in Figure 1 with good 
success. 

In Figure 1, if ADDLIBLE is not successful, it will be reported that CPF2103 (library already in 
library list) was the error encountered. Of course, a CANCEL is rather severe for such a trivial 
error, however, a RETURN might be more appropriate 

Now I have to consider the severity of my messages and take options (based perhaps on a third 
parameter) to CANCEL or RETURN from my ERROR procedure and continue. 
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From: R. L. of Mt Kisco, NY To: S. K. of Woodbury, NY 


An interesting problem.and potentially dangerous, thanks for bringing it up. Have you tried 

the AS/400 command MONMSG under the S/36 Spec Env?or does it give the same results as 
just comparing 7MSGID? to specific values? 

From: S. K. of Woodbury, NY To: R. L. of Mt. Kisco, NY 

Regarding MONMSG, I have not tried that in an S36 environment OCL36 procedure. However, 
I think it should work just fine... like all native commands in S36 environment. Also, I use 
7MSGID? to see, in general, if any error occurred. I use MONMSG to trap for a particular error 
and take corrective action as needed. 


Next 


Home 


Previous 










MIDRANGE 

COMPUTING 

HR PUBLICATIONS INC. 


AS/400 Database Implementation 


June, 1989 

Copyright 1989, Midrange Computing 


by Dick Eagleson 

Meat, Vegetables, Commitments and Black Holes 

With several installments of what you might call "generic" database concepts and terminology 
now complete, you can turn your attention to the "name brand" AS/400 database management 
system (DBMS) with a better understanding of what you see. As with many other aspects of the 
AS/400 computing environment, the machine's DBMS is something of a law unto itself; not 
exactly relational and not exactly like anything else either. It is always useful to be able to view a 
piece of hardware or software against a background that is more extensive than just the product 
itself. 

Physical Files 

Database management is about fields, records and files. The most basic manifestations of all of 
these items on the AS/400 are found in so- called physical files. 

A physical file has a lot of characteristics taken straight out of the relational data model. In 
particular, all records in any given physical file must have the same format. 

Fields 

The fields making up the records of a physical file may be drawn from a small repertoire of 
supported types. There are, to begin with, the "usual suspects" familiar to System/36 
programmers — alphanumeric character, zoned decimal, packed decimal and binary fields. 

With respect to allowable field sizes, there will be a few surprises when compared to System/36 
practice. One is the upper limit of 32,766 bytes for alpha character fields; a very significant 
departure from the 256 byte limit for such fields in RPG programs. 

Cosmopolitan 

It is undeniably true that, for now at least, the IBM midrange market is very heavily oriented 
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toward RPG as the principal programming language. 

But the reliance on RPG was never total, even back in the System/3 days. Items like the different 
treatment accorded field size limits in the AS/400 DBMS and RPG/400 just serve to point up the 
fact that the AS/400, no matter its roots, is not an "RPG machine" — a claim made both by some 
of its partisans and by some of its detractors. 

The AS/400 offers more choice of programming languages than any of its predecessor platforms. 
The AS/400 DBMS, which serves all supported languages, must necessarily, then, impose no 
artificial constraints on the implementation of any one of them. 

To the extent that old RPG hands, from the System/36 or elsewhere, see aspects of the AS/400's 
software architecture that cannot be explained in terms of RPG, the basis of the puzzling features 
probably lies in some one of the additional programming languages supported. 

Floating Point 

A case even more in point than very large alpha fields is that of so-called floating point numeric 
fields — something of which the RPG language, and most of the AS/400's midrange 
predecessors, were entirely innocent. 

Or perhaps the proper word is bereft. The support of floating point arithmetic computations has 
figured prominently in the design of the so-called "supermini" machines, including the DEC 
VAX. These machines, designed with the engineering and scientific user communities primarily 
in mind, can also do business-oriented data processing. They have, in fact, been IBM's principal 
midrange DP competitors. 

IBM, given the nearly pure DP orientation it has always had in mind for its midrange machines, 
left out floating point arithmetic support on the hardware periphery and left it out of the RPG 
language altogether. 

97 Lb. Weakling 

The AS/400 processor does floating point arithmetic — and also trigonometric and other complex 
math functions — using routines coded in the machine's so-called Horizontal Microcode. This 
lowest level of firmware directly controls the processor hardware from its home in the 
processor's control storage. 

This is, in a sense, hardware support for floating point arithmetic. But the bare processor 
hardware of the AS/400 is not basically oriented toward, nor optimized for, floating point 
numeric computation. 

Heavy number crunching is almost always supported, these days, by fitting a special purpose co¬ 
processor alongside a general purpose main processor. PC's have Intel's 8087, 80287 and 80387 
chips or Weitek's 3167 for this purpose. IBM's own RT-PC uses a floating point coprocessor. 
IBM's mainframes can have entire, specially built floating point array processors strapped on 
when numbers must be crunched wholesale instead of retail. The AS/400 is almost unique in 
IBM's product line for having, as yet, no comparable "steroid on a chip" to pump up its floating 
point arithmetic performance. 
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So What? 


Which raises a legitimate question for longtime IBM midrangers — "Just what are floating point 
numbers anyway, and why should I care about them?" 

To answer the last question first, you very well may not care. But tomorrow's business 
applications will not necessarily be just straightforward evolutions of yesterday's and today's. 

IBM will almost certainly hang genuinely capable floating point arithmetic hardware on the 
AS/400 before long. Every programming language supported on the AS/400 — except, as noted, 
RPG — already has the ability to deal with floating point operands. Times are changing. Never 
say never. 

Floating Point Explained 

Floating point numbers, unlike the familiar zoned decimal, packed decimal and binary types, are 
not necessarily exact, only approximate. 

They were designed to meet a requirement often encountered in running programs to solve 
complex mathematical equations by numerical approximation — how to represent both very large 
and very small numbers without using huge numeric fields. For example, just solving equations 
that describe simple conic sections or trigonometric functions routinely involves coordinate 
values that asymptotically approach either zero or infinity. 

The solution to cramming big numbers into small spaces was to trade accuracy for range. 

A four-byte binary number, for instance, represents one and only one value. But the value falls 
somewhere in the range from roughly negative two billion to positive two billion. 

All such values are also integers. If your problem involves fractions — especially very small 
fractions — fixed point binary numeric representation cannot do your job. 

A four-byte floating point number is represented in a kind of binary version of scientific 
notation. It is a signed mantissa value having a signed exponent. The typical split is 11 bits for 
exponent and 21 bits for mantissa. This allows for a value range from minus to plus 10 to the 
roughly 300th power. 

To represent the exact values of numbers this large, you would need numeric fields 128 or more 
bytes long. Floating point representation says, in essence, "Only a few digits of numeric 
significance are important for most computations. Therefore I will trade all but 2-1/2 bytes worth 
of what would otherwise have to be 128-plus bytes of numeric exactitude for the ability to work 
with much bigger and smaller numbers." 

Because of accumulated rounding errors, not all computations can be usefully done with so little 
retained numeric significance, of course. A 21-bit mantissa gives only the equivalent of seven 
significant digits. Most machines, and programming languages, that support floating point 
operands also support a longer type known as double precision floating point. Double precision 
operands are eight bytes, rather than four bytes, in total length. The extra bits are used to add to 
the number of significant digits carried along in calculations. 

The AS/400 supports both a single precision, seven significant digit form of floating point 
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number, and also double precision floating point fields having 15 significant decimal digits. 

Soup Chef 

Having detoured to consider the various types of "meats" and "vegetables" from which you may 
make file "soup," let us now return to the matter of recipes. 

First, there is the size of the "pot" to consider. The AS/400 restricts — if that is the word — record 
length to the same upper limit as allowed for single alphanumeric character fields — 32,766 
bytes. 

If lots of little fields, rather than one big one, is your inclination, be aware that the AS/400 will 
also send any record definition served up with more than 8,000 component fields back to the 
kitchen. 

Order Taking 

Files are most useful when you can find, as well as store, things in them. In an application 
designed according to strictly relational data model considerations, every physical file would, 
therefore, have a key defined. 

The AS/400 DBMS is not relationally rigorous in this sense. If one of your applications uses files 
in a strictly sequential fashion — quite likely in the case of code ported from a System/36, for 
example — then its physical file definition on the AS/400 need not specify a key. In such cases, 
physical files are said to be accessible only in "arrival sequence;" meaning the records in the file 
appear when they are read in the same order in which they were added. This is referred to as 
using the arrival sequence access path. 

If a key is specified, you can get at file records using a keyed sequence access path. A physical 
file can have only a single keyed access path. If this sounds like a step backwards relative to the 
System/36, don't worry. Further on, you will see why this limitation does not constitute a 
restriction on good system design. 

The use of the "access path" terminology for both keyed and non-keyed record reads may also 
seem a bit confusing from a System/36 point of view. The term seems to refer to something like 
an index. In the case of a keyed sequence access path this is exactly right. A real index is 
maintained for the file's records. 

Given the storage space allocation techniques used by the AS/400, though, you can think of 
whatever private data structure that the AS/400 uses to point to all of the component bits of space 
making up a file as also being a kind of index. Thus, some kind of data structure that points to 
records is being searched or traversed whenever any kind of read operation is performed. The 
effective difference between processing sequential, as opposed to indexed, reads, then, is not as 
large as is the case with the simple file system of the System/36. 

Keys for physical files are roomier than System/36 users are used to. The upper limit on key size 
is 120 bytes. A given key can consist of any number of fields that do not, in combination, exceed 
120 bytes in stored form. 

Note that the Data Description Specifications (DDS) — which are lines in an RPG-like language 
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used to define files on the AS/400 — require you to code field lengths in terms of decimal digits 
or bytes, not their lengths in stored form. For alpha character and zoned decimal numeric fields, 
the relationship is one-to-one anyway. The digits/length conversions for packed decimal and 
binary fields are the same as on the System/36. Floating point fields, as mentioned, are either 
four or eight bytes in length. 

The AS/400 goes additional big steps beyond System/36 practice in access flexibility and 
customization. The order in which the multiple fields of a composite key are specified for the 
key need bear no resemblance to the order in which those same fields are first defined. 

Also, each field of a key may be treated in any special way which will produce the sequence of 
record retrievals you desire. In a composite key, for instance, some fields can sort in ascending 
sequence — the default — while others are in descending order. Duplicate key values can be 
allowed or not as you like. If duplicates are allowed, you can specify whether the records that 
contain them are to be fetched in LIFO or FIFO order, relative to when they were added to the 
file. Alternate sequence substitutions and special handling of numeric key fields — the use of 
absolute value rather than signed value ordering, for instance — can be specified. 

File Compiling 

I used the word language to describe AS/400 DDS because it is, in functionality and fact, 
something separate from RPG. I emphasize this point because the fact that DDS has a coding 
form of its own that looks very much like some additional kind of RPG specification ("A-specs") 
tends to obscure this matter. The fact is that compiling an RPG program and creating a physical 
file are entirely separate activities. 

Both, though, are essentially compilation steps. In the case of RPG, compilation produces an 
executable object program as output. In the case of DDS, compilation — by a Create Physical 
File command — produces a new file entry in a library directory; its record format name, field 
names, types and key definition become known to the system. Pushing data at this file causes 
space to be allocated and real records to be written. 

Out There, Somewhere 

Unlike the readily understandable — if not especially flexible — System/36 file system, the 
AS/400 DBMS doesn't show you exactly where your records are kept in terms of the attached 
storage devices. 

How indexes are kept and maintained is also an utter mystery to the typical AS/400 user — at 
least in terms of being elaborately documented in any readily accessible IBM publication. 

Angst 

These things, more than any others, tend to make users who have "graduated" from a nice, 
straightforward environment, like that of the System/36, nervous. 

In a sense, this is reasonable. On the System/36, and previous machines in IBM's midrange line, 
you were used to knowing the details of file system function. On the AS/400, you don't, and it 
feels strange. 
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But this anxiety is not really justified, and I'm going to knock the cobwebs off a sermon I used to 
preach occasionally about the System/38 to explain why. Users who came to that machine from 
System/3 and System/34 backgrounds had the same misgivings. 

I point out first, that mainframe assembly language application programmers suffered the same 
pangs when they were forced to switch to COBOL, PL/I or any other high-level language that 
generated "mysterious" executable code. 

IBM midrange users have not, by and large, ever wondered too much about their object code. 

But the point is that the missing information that makes you feel discomfort doesn't actually have 
to be useful knowledge, you just have to miss it when it isn't around anymore. 

Some of you who go back as far as the System/3 days may even remember that moving from an 
all-punched-card Model 10 to one with disk drives made certain folks nervous. They didn't 
believe in data that they couldn't hold up to the light and look through. 

Excess Baggage 

In a sense, knowing how files were allocated and how indexes were constructed on the AS/400's 
ancestor systems never really did any of us any good. The "policy," so to speak, which governed 
these matters was not influenceable by us in any meaningful way. 

The data structures that are used to maintain the index associated with an AS/400's physical file 
key definition are much more involved than the simple ordered list of keys and pointers we've all 
come to know — if not love — on the System/36. But we can't influence the way the one works 
any more than we could the other. 

The same applies to allocation. Sure the AS/400 will squirrel away little pieces of each of our 
files all over the DASD map. So what? If we can't influence where the pieces go, would it make 
any difference if we knew where each one ended up? 

Do we think we could do a better job of allocation than the IBM algorithms? Anyone can 
optimize file placement for a single-task, single-user system, but the AS/400 is neither. 

There is a UNIT parameter that allows you to identify a particular disk drive as the intended 
home for a new file, but the control it offers is crude. Letting the system scatter records hither 
and yon by itself improves average access time and maximizes simultaneity of access to any 
single file. 

From a strictly logical viewpoint, it makes more sense to wonder why so few people seem to 
understand — or are even curious about — matters that are more involved than the System/36 or 
AS/400 file systems, but that a user can exert some influence over. The performance 
measurement tools and tuning strategies of the two machines come readily to mind. 

Logical Files 

If physical files are the owners of record of the records, so to speak, then logical files are a bit 
like renters; they're attached to the same property and in most respects can look just like the real 
owners. 


Next 


Home 


Previous 








Alternate Indexes 


The simplest kind of logical file is called — in a rare case of IBM terminology that is neither 
obscure nor different just for the sake of being different — a simple logical file. The principal use 
of simple logical files is to support additional access paths to records that are owned by a 
physical file. Just as with physical files, each logical file can have only one key defined. You 
merely define a separate logical file for each second or subsequent alternate index you want to 
maintain on the records of a given physical file. 

Cut, Shuffle And Deal 

Simple logical files can also act as filters for the records of a physical file. Not every field 
defined in a physical file has to be defined to a logical file built over the physical file. Criteria 
can also be supplied for selectively bypassing whole records from the physical file. Logical files 
provide a simple way of enforcing certain kinds of access restrictions. 

These filtering functions of a logical file bear a strong resemblance to the select and project 
operations of the relational algebra. The differences are two. First, is that logical files are 
accessible one record at a time instead of all at once as an entire result file. 

The second difference lies in where binding takes place. The select- and project-like functions 
embodied in a logical file definition only become realizable after that definition is compiled with 
a Create Logical File command. Most relational systems, in contrast, bind selection and 
projection operations dynamically, as they are specified. 

Two other kinds of logical files provide additional abilities to recast data from one or more 
physical files into forms that enable applications to be coded which contain no excess baggage. 

Multiple Format Logical Files 

The header-record-and-one-or-more-trailer-records type of file has been a staple of application 
design for a long time — especially for batch processed items such as reports. 

Of course, using the AS/400 DBMS, the underlying reality is one of physical files, each of which 
contains records having one — and only one — format. The multiple format logical file is a 
mechanism provided by the AS/400 that allows the records from two or more physical files to be 
accessed in a header-and-trailers fashion. 

Specifically, an access path index is built that points at records from two or more physical files. 
By basing the key on at least one field that all of the given physical file records have in common, 
most of the job of aggregating these disparate records into groups having common key field 
values is done automatically. 

The final job is making sure that, for each key value, the order of record presentation starts with 
the physical file holding the "header" records, then proceeds with records from one or more 
"trailer" files in the desired order. This is handled by making sure the DDS record specifications 
are declared in the same order you want to see the trailer record types appear when read. 

Join Logical Files 
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Just as simple logical files can be made to do things reminiscent of relational project and select 
operations, the AS/400 DBMS also provides a special type of logical file that can do join-like 
things. The name of such an entity is, naturally enough, a join logical file. 

As with simple logical files, the main differences between AS/400 join logical files and the join 
operations offered by more purely relational DBMS's are in the read-a-record-at-a-time mode of 
access and the compile-before-use binding of the join logical file. Rather than specify join 
operations on the fly, the AS/400 join logical file requires you to "plan in advance of need" as 
the folks at Forest Lawn like to say. 

Also as with simple logical files, this "hard-wired" compiled join can definitely be a feature — 
not a bug — for many applications. If you definitely know that a given set of physical files are 
destined for a lot of necessary joinery, there is considerable machine efficiency to be gained by 
binding a join logical file once and accessing it many times in preference to dynamically joining 
the same files many times on the way to achieving the same results. 

While most joins specified in relational queries only involve a pair of files, it is not all that 
unusual for three or even four files to wind up needing to be zipped together to answer some 
given question. A join logical file allows up to 32 physical files to participate and contribute 
fields to its synthesized output records. 

Just as in joins specified for dynamic evaluation in more fully relational systems, the join logical 
file requires that you specify a multi-file join as an ordered series of simple joins involving pairs 
of files — file A to file B, file B to file C, etc. 

In addition to specifying the fields along whose values each sub-join is to be performed, the DDS 
description of a join logical file also allows a key to be defined from fields in the composite 
record format of the file. This allows application programs to start accessing a join logical file at 
points other than the sequential beginning. 

Readin' An' Writin' 

If database management is all about fields, records and files, it is especially about how to let 
multiple users get maximum access to those data resources with a minimum of collision and 
friction. All multi-user systems provide some kind of record locking protocol that allows users — 
at least the ones with no taste for Russian Roulette — to construct applications that properly 
arbitrate competing requests for any single record. 

The AS/400 DBMS sticks closely to multi-user file system practice in requiring applications to 
declare their general intentions at the time they request access to a file. Applications that want 
the ability to add to, update or delete from a file must use appropriate parameters on the OPEN 
request issued for that file. 

Islands Of Update 

In general, applications that add, update or delete data fall into two categories, those that target a 
single record, and those that usually or always affect two or more records. 

Applications that do all of their work in terms of a single record have the nice property that they 
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don't impose any hidden connections among two or more records in the same or different files. 
Updating the mailing address in a customer master record, for instance, is a self-contained ki nd 
of operation. Making that change doesn't automatically imply that anything else needs to be done 
to any other record of any other file. 

Adding a record to an order detail file, on the other hand, might well imply a need to update one 
or more totals in a corresponding open order master record in a second file. 

Drawing The Line 

The AS/400 provides a number of facilities aimed at segregating updates from one another well 
enough to avoid file corruption. The most draconian is for an application to open all of its files 
for exclusive use. This sure takes care of the update interloper whose own job might want at 
those same files, but the cost of the coverage is that whole files stay out of circulation for 
extended periods. 

The generally more acceptable solution is to share access to the files, but ensure that only one 
process at a time gets a whack at updating any particular record. 

The AS/400 automatically locks records read from a file opened for update. Only one lock per 
open file is supported; read a new record from an update-capable file and the lock on the record 
gotten previously from that file — whether it was updated or not — is released. For many 
applications — especially those single updated record types — this is perfectly adequate 
protection. 

Head-Scratching Time 

Of course there is still potentially a problem even with single record locks. The simplest way to 
write applications that fetch and update one record is to read the thing, put it up on the screen, let 
the user take his or her time thinking about what changes to make, let the user poke the changes 
in at whatever keystroke rate is manageable, then write the record back out when the ENTER 
key is finally pressed. 

A record under update can wind up locked for a considerable time under this protocol. The 
AS/400 queues up any other jobs that want a crack at a locked record and lets them wait. But the 
default wait limit is 60 seconds, after which each such job gets a "no can have" status back 
instead of the record it wanted. 

For some updates, 60 seconds may be all the time in the world. For others it may be too short. 
The lock wait interval is adjustable, but fiddling with it is less satisfactory than doing something 
else entirely by way of avoiding such little digital thromboses. 

Double-Clutching 

A way out of this problem — albeit at the expense of complicating the application code somewhat 
— is to adopt the following basic single-record update logic: (1) read and lock the record, (2) set 
aside the updatable field values, (3) immediately write the record back out to shed the lock, (4) 
display it for update, (5) let the user think about and key in updates at whatever pace seems 
natural, (6) when the ENTER key is pressed reread and lock the record, (7) check the updatable 
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values against those saved from the first read, (8) apply the user's indicated updates if nothing 
changed between first and second readings of the record, (9) else inform the user that the 
transaction must be redone, then re-do it. 

The only thing really wrong with this approach is that it requires the application programmer to 
write a lot of keeping-track-of code of a very stereotypical kind. Even if it was never IBM's 
intention to offer direct support for file-at-a-time relational algebra operations, the AS/400 
DBMS really should have opted for the support of higher-level operations than it wound up with 
even at the individual record level. 

To be exact, the AS/400 needs three things. The first is a PRE-READ operation that would 
automatically copy and set aside all field values passed to the application program. 

The second is an explicit UNLOCK operation that would release a single record lock without 
requiring the full processing of a write operation. 

Last, is a RE-READ operation that would read a record and compare the field values gotten to 
those saved by a prior PRE-READ. The returned status code from a RE-READ would cue the 
do-the-update/re-do-the- transaction application logic. 

Multi-Record Update 

As you can see, even single record updating has its subtleties in a multi-user environment. The 
really tough thing, though, is adequately handling updates in which two or more records have to 
be changed as a semantically significant unit. We already offered the example of order detail and 
header records. Debiting one General Ledger account record and crediting another is an 
additional common example. The necessity for multi-record updates that must all be done in 
sync arises rather frequently in application design. 

For such situations the AS/400 offers something called Commitment Control. You start it with 
the STRCMTCTL command and end it with the ENDCMTCTL command. 

What Commitment Control does, in brief, is make record locks more persistent. If you read two, 
five or a hundred records from a given file or a dozen files — and update them all — the AS/400 
under Commitment Control will retain the locks on all of them — up to a maximum of 4096 — 
until you perform a COMMIT operation (COMIT in RPG), at which time the locks are all 
released. 

Journaling And Rollback 

Why is this different from just doing single record updates on all of these records one-at-a-time? 
Recoverability. 

Under Commitment Control you have to journal your updates. A before and an after version of 
each updated record is written to a journal file, tagged with your job ID and other information 
that allows the thread of updates performed by any given job to be traced back later. 

Journaling is always a good idea — and for the access path indexes on your system as well as for 
the files. Updates get physically written to a journal file before they get posted to the file or 
access path being updated, making the journal always the "freshest" record of what is happening 
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on your system. When not under Commitment Control, however, it is possible to do only after 
image journaling or even no journaling at all. Not recommended. 

What the full journaling under Commitment Control buys you is the ability for your applications 
to quickly "back out" all record updates made since the last time a COMMIT operation was 
performed by issuing a DECOMMIT operation (ROLBK in RPG). Record updates, at this point, 
have been done, but consulting the journal file allows them all to be restored. 

Deadly Embrace 

This incremental "rewind" ability simplifies your job of writing robust application code that can 
abandon a complex set of interrelated record updates at any point and still not bollix your files. 

The most usual reason such an update set would have to be restarted would be that one of the 
records wanted for update had already been acquired and locked by some other job. In a 
Commitment Control environment, it is much more probable that such a thing will happen, at 
least compared to the situation with the PRE-READ/RE-READ logic for single record updates. 

This is because the keeping of record locks across multiple updates will usually include all of 
that "head- scratching time" that the PRE-READ/RE-READ protocol avoids for single records. 

If you can't safely bail out of a stalled transaction under such circumstances, you wind up in the 
dreaded "deadly embrace" — job 1 has record A and wants B; job 2 has record B and wants A; 
neither can budge. DECOMMIT allows potential deadly embraces to be broken before they lock 
solid. 

Deferments 

A lot of the speed of AS/400 data management accrues from a design strategy of taking 
calculated risks. File and access path updates, for instance, may not get written to disk for quite 
some time after they get made. Instead, the memory-resident versions of those records and access 
path parts are updated and "read" from when other jobs need to use them. 

As mentioned, such updates do go promptly to any specified journal files. Thus, the good 
performance allowed by caching blocks of file and access path data can be backstopped by 
proper journaling. 

After Hours 

Another example of work shifting is in the updating of access paths. Suppose you run a job that 
uses a physical file and a logical file to provide two different ways of getting at the same records. 

If you make any record updates that require either or both of the access paths to be updated, they 
are — immediately. 

But suppose that the physical file you updated also has several other logical files defined on it 
that you do not use in the job that did the updates. The problem is that these currently inactive 
logical files all have access paths that may need updating too. Should the AS/400 do the updates 
now, or wait? 

The answer is — take your pick. Logical files can be parameterized to tell the AS/400 to; (1) 
always do needed access path updates right away, (2) save up any updates until the next time the 
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logical file is OPENed and post the updates as part of the OPEN process, or (3) ignore updates 
and always rebuild the access path from scratch as part of its OPEN process. 

The first choice keeps things up to date, but not always in ways that are instantly needful. Doing 
all access path updating on a pay-as-you-go basis just slows down transactions that may be very 
frequently performed. If the paths being updated are only used infrequently, the trade is not a 
good one. 

The third choice is generally quite wasteful. That leaves the middle choice as the percentage 
play. 

Dropouts 

One of the more disappointing design choices in the AS/400 DBMS is its method of handling 
record deletions. In many modern file systems and DBMS's, a record that is deleted is physically 
deallocated as well as logically removed from indexes, etc. 

The AS/400 doesn't quite do this. When you delete an AS/400 record, it does logically disappear 
from the access paths of its physical file and any logical files that reference it. But, the record is 
still physically allocated to its physical file — a "stealth" record, so to speak. 

You can even cause the storage space to be reused by explicitly writing a new record into the 
vacant slot using a WRITE operation that picks up the relative record number of the deleted 
record from a numeric control field. 

Bad Trade 

One obvious reason for leaving little "black holes" in files from which records have been deleted 
is to preserve the relative record numbers (RRN's) of the records in the same file with a later 
arrival sequence. If deleted records were entirely removed, all records above a delete in arrival 
sequence would have their RRN's bumped down by one. 

The thing is, if you never accessed such a file by RRN, then what could be hurt? For files that 
you do want to access by RRN there should be a DDS option that does this same kind of not- 
quite-gone deletion now done in all cases. The vast majority of deletes, however, would more 
sensibly reflect the intentions of application designers if the physical records thus dropped were 
deallocated from the file at the disk block level — made to entirely disappear. 

As things stand, the only way to squeeze a growing population of deleted records out of a file is 
to issue a Reorganize Physical File Member (RGZPFM) command. This amounts to a batch 
"garbage collection" pass. It should not be necessary to indulge such archaism on a machine that 
is otherwise fairly well designed as an on-line application platform. That old IBM batch 
mentality dies pretty hard I guess. 

Conclusion 

Short of the foot-thick stack of manuals IBM puts out on the subject, it is impossible to provide 
an entirely comprehensive look at the AS/400 DBMS. This has admittedly been a little like one 
of those "13 countries in 10 days" deals, but the AS/400 DBMS is a big place and a visit to every 
twisty little side street wouldn't be over until all of us were a lot older. 
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We'll delve a bit further next time when we look at the problems of the new immigrants from the 
System/36 "old country." 
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The AS/400 offers a world of new possibilities, new experiences, and, unfortunately, new bugs. 

It is impossible for a novice AS/400 programmer to avoid these pests. Even those experienced 
with the very similar System/38 manage to have a run in with these creatures more often than 
they would like to admit. 

IBM recognized that such a powerful and complex machine could produce bugs of the most 
formidable strain, so they provided each system with equally uncompromising weapons. Easier 
to use than a can of RAID, the AS/400 debug facilities can seek out and destroy the most 
tenacious of pests. 

Any High Level Language or CL program can be debugged, without changing and compiling it. 
You need only tell the computer at what point (breakpoint) you want to peek inside the executing 
program. Once "inside", you can examine program variables and even change them to influence 
the natural course of the program. You can also trace a program's processing sequence, 
displaying the statement numbers executed and the values of variables at each statement in the 
sequence. 

We will only discuss the debugging of interactive programs. Batch program debugging requires 
advanced techniques that can be avoided altogether by temporarily running the batch job in 
interactive mode. 

Options 

There are two ways to debug a program on the AS/400. The most versatile is by the use of 
breakpoints. By specifying breakpoints in program flow, you can have a program pause at one or 
more locations for examination and possible modification of the field contents and the indicator 
values. 

The other method is to trace the sequence of statement execution. In other words, you can 
monitor the exact flow of the program, statement to statement. Lurthermore, you can display the 
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variable values at each statement in the procession. 

Setting up a Testing Environment 

On the AS/400 there are production libraries and there are test libraries. IBM designed these two 
types of libraries to provide a guarded approach to debugging and testing. While debug is 
running for an interactive session, you cannot run a production library program that updates or 
adds to a file or modify a source member (from that workstation) — unless you change a default 
parameter value when starting debug. This is easy enough to do, but clearly the intent is to 
influence you to do all your testing in a test library. This game plan has its merits and should be 
followed. 

The Create Library command (CRTLIB) and the Change Library (CHGLIB) command assign 
and change the attribute of production or test. 

Before you test and debug, create a test library (a library type of *TEST) and copy applicable 
production library objects into it. You can then perform all testing in the test library without 
harming your production data. Here is an example of creating a test library named TESTLIB and 
copying the contents of a production library into it: 

/* Create test library */ 

CRTLIB LIB(TESTLIB) + 

TYPE(*TEST) 

/* Copy production library to test library */ 

CPYLIB FROMLIB(PRODLIB) + 

TOLIB(TESTLIB) + 

CREATE(*NO) 

At this point, you would be ready to Start Debug (STRDBG) for library TESTLIB. 

After testing and program maintenance is complete, you simply copy the modified programs 
back to your production library. The test library can then be deleted. 

Starting Debug 

You can activate the debugging facilities for a program or group of programs with the Start 
Debug (STRDBG) command, which allows you to place up to 10 programs into debug mode. 
The current library, the library list, or a specific library can be specified to locate each of the 
programs. 

Debug session attributes can also be specified. The Default Program (DFTPGM) parameter 
allows a program to become the default program for any of the other debug commands used 
during this session. 

The Maximum Trace Statements (MAXTRC) parameter indicates the maximum number of 
statements that can be placed in the trace file before the action specified in the Trace Full 
(TRCFULL) parameter is taken (see TRACING section later in this article). 

The Update Production files (UPPROD) parameter is used to indicate whether production data 
files and source physical files can be updated during the debug session. The default is *NO. You 
can change this to *YES, but the safest method is to move your objects to a test library. Be very 
careful if you specify *YES because you could inadvertently alter your data base during the 
debug session. 
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Once debug has been started, you can change any debug attributes at any time with the Change 
Debug (CHGDBG) command. 

You can add programs to the current stack of programs in debug mode with the Add Program 
(ADDPGM) command. You can remove them with the Remove Program (RMVPGM) 
command. 

Debug mode stays active for a program until RMVPGM is used, until End Debug (ENDDBG) 
cancels all debugging activities for that job, until the job is terminated, or until the program is re¬ 
compiled. To reset a recompiled program for debug, you will have to deactivate it with 
RMVPGM and then reactivate it with ADDPGM. 

If you lose track of what is being debugged, you can use the command DSPDBG to display the 
current stack of programs being debugged. In addition, you will see the current statement 
number, the recursion level, and the type of breakpoint (if used) for each program. 

Setting Breakpoints 

A breakpoint is a specific location in a program, defined by a program statement number, a label, 
or an MI instruction number, where you want the program to pause for your inspection. You can 
determine a program statement number by either looking at a compile listing of the program, or 
using the sequence number displayed by SEU in browse or edit mode. However, the statement 
number displayed by SEU must be multiplied by 100. For example, SEU statement 59.00 would 
be 5900 in the ADDBKP command. 

A label can be many things. In an RPG program, it can be a TAG statement, an operation code, 
or the beginning of an RPG section. The start of an RPG section is specified by choosing UNIT, 
*DETL, *GETIN, *TOTC, *TOTL, *DETC, *OFL, or *TERM. These special words indicate a 
specific point in the program. For example *TOTC means the beginning of total calcs, and 
*TOTL is the beginning of total output. A CL program label can be a statement identified by a 
label or a DO or ENDDO statement. In the case where there is more than one label with the same 
name, a new breakpoint replaces the previously added breakpoint. 

A breakpoint occurs just prior to the execution of the statement specified. When a breakpoint is 
reached, a Breakpoint screen will be displayed (see Figure 1). You can do one of three things 
from this display: 

|1. Continue processing by pressing Enter. 

2. End the most recent request by pressing F3. 

3. Go to a command entry screen by pressing F10. 

From the command entry screen you can: 

Enter any CL command that can be used in an interactive debug environment. For |TAG 
SYS| example, you could add or remove programs from debug mode, or display or change 

variables in the program. 

Continue processing the program by entering the Resume Breakpoint (RSMBKP) |TAG SYS| 

command. 

Return to the breakpoint display by pressing F3. 

Return to the command entry display at the previous level by entering the End 
Request (ENDRQS) command. 

Tracing 

Once you have started debug, you can specify the tracing details with the Add Trace (ADDTRC) 
command. The ADDTRC screen prompts you for up to five ranges of statement numbers to 
trace. You can also specify up to 10 variable names whose contents you want displayed when 
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referenced in a traced statement. 


When a traced program is run, information is recorded into a trace file and can be viewed after 
the trace has been completed. The maximum number of statements (1 - 200) that can be recorded 
in a trace file is specified on the STRDBG or CHGDBG command. These commands also let 
you choose the action to be taken when the trace file becomes full. Specifying *STOPTRC in the 
TRCFULL parameter will force a breakpoint. The trace file will be extended if the user 
continues. If *WRAP is used in the TRCFULL parameter, the trace file is overlaid with new 
trace statements as they occur, wrapping from the beginning of the file. 

Display Trace Data (DSPTRCDTA) is used to display the trace information record in the trace 
file. It contains a list of the statement numbers executed and any traced field names that were 
referenced (see Figure 2). You can view the trace data while the program is active by 
interrupting it with the ATTN key (assuming the ATTN key program is QCMD), or by use of a 
breakpoint, followed by pressing F10 to get to command entry. The trace file is cleared with an 
option on the DSPTRCDTA command or by the CLRTRCDTA command. 

You can remove from 1 to 5 trace statement ranges at a time, or remove all ranges with the 
Remove Trace (RMVTRC) command. 

An interesting technique is to use the trace function to step through program statements one at a 
time by setting the MAXTRC parameter to 1 and the TRCFULL parameter to *STOPTRC in the 
STRDBG or CHGDBG command. As each statement within the trace range is executed, a 
breakpoint display is forced and an error message is displayed indicating the maximum number 
of trace statements has been reached. By pressing the error reset key followed by the enter key, 
the next statement is processed and another breakpoint screen is displayed. From the breakpoint 
screen you can go to command entry and display the trace data (DSPTRCDTA), or display or 
change any of the program variables. 

References: 

Control Language Programmer's Guide (SC21-8077-0), Chapter 11 Control Language 
Reference, Volume 2 through 5 (SC21-9776-0 through SC21-9779-0). 

RPG/400 User's Guide (SC09-1161-00), Chapter 4. 
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I would like to address the operating speed of the AS/400. Actually, I am referring to the 
perceived operating speed. A job seems to run faster when messages are displayed notifying the 
workstation operator of the current processing. An example for the S/36 would be: 

// * ’Sorting Customer File' 

// * 'Printing Customer Master List' 

The AS/400 command SNDPGMMSG can be used for this purpose. However, the command 
parameters must be correct for a neat status message at the bottom of the screen. Otherwise you 
will get a display of the PROGRAM MESSAGES queue. The old S/34 to S/38 conversion aid 
produced such messages and they are out of the question for a user interface. Figure 1 shows an 
example from one of my programs. 

The IBM message identifier CPF9898 can be used for application messages and displays the 
message data followed by a period. Be sure to send the message to the external program queue 
(TOPGMQ(*EXT)) and use M S G TY P E( * STATUS). 

Jonathan E. Yergin Gainesville, Georgia 

Figure 1 Example of SNDPGMMSG command 

SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG.QSYS) + 

MSGDTA('REMOVING QPRGSRC.TEST member' *BCAT + 

&SRCMBR) TOPGMQ(*EXT) MSGTYPE(*STATUS) 
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by Midrange Computing Staff 

If you ever find yourself without matching source code for a CL program, you can create it with 
the RTVCLSRC command. The following command will create source member TEST in source 
physical file QCLSRC in library TESTLIB from program TEST in the same library: 

RTVCLSRC PGM(TESTLIB/TEST) + 

SRCFILE(TESTLIB/QCLSRC) + 

SRCMBR(TEST) 
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by Jonathan Yergin 

Here is an example (Figure 1) of renaming fields from an external file to array elements so they 
can be referenced by an index. Refer to Input Specifications, EXTERNALLY DESCRIBED 
FILES in the RPG Reference Manual and Programmer's Guide for more information. Note that 
the display file fields must be defined as B, both input and output. To prevent input, you may 
specify DSPATR(PR). 

Jonathan E. Yergin Gainesville, Georgia 

Figure 1 Renaming external fields to array fields 
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by Midrange Computing Staff 

Every AS/400 programmer knows that the F4 function key initiates the command prompter 
which provides assistance in completing and submitting CL commands on the screen. But did 
you know that you can also use it in SEU when keying a command in a source member! 

Place the cursor at the SEU statement you want the command placed. If you do not know the 
proper command name, press F4 to peruse all the commands by major command groups until 
you find the command you want. If you know the name of the command, key it and press F4. 
Then, just complete the command screen as you normally would, using F4 to get help for any of 
the parameters. When you finish with the parameters and press enter, the command will be 
neatly written to the source member statement in the proper position. 

This feature is just one more of the many on the AS/400 that help keep the manuals off your 
desk. 

DataNetwork Staff 
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Selected from DataNetwork's electronic bulletin board, TELEFORUM 
From: D. B. of Creston, IA To: All 

We have a 5360 model D24 with 1 MB of memory, 400 MB of disk, 36 local devices, and 3 
remotes. Currently, we are using about 75% of disk space. 

We are looking at AS/400 prices (scary) for a model B40 with 12 MB of memory and about 2.5 
GB of disk. Can any AS/400 users out there give me a feel if this is decent size configuration? 

Don't want to come in too small, but we need room for growth. We don't want to dump a bunch 
of money if not necessary. Any suggestions or comments welcome. 

From: C. M. of Marshall, MN To: D. B. of Creston, IA 

Just to give you an idea of the size of AS/400 you should get as a minimum size, IBM suggests 
that you should get at least 2 times the DASD and recommend a 1 to 8 ratio on memory. When 
we went to the AS/400 back in October, we were not sized properly and had all kinds of 
problems. We went from a S/36 with 800 MB DASD and 1.7 MB memory to an original 
configuration of 1200 MB DASD and 8 MB memory. Since then we have added 400 MB more 
DASD and 8 MB more memory. Our AS/400 is running well now with the 16 MB memory and 
1600 MB DASD. By the way, we have a model B30. 

From: M. R. of Troy, MI To: D. B. of Creston, IA 

What's even more scary is you'd better figure out how you're going to back up 2.5 gb of data in 
less than 3 days!!! This problem has not, to my knowledge, been solved yet. 

From: A. T. of Spotswood, NJ To: D. B. of Creston, IA 

I just converted a client from a S/36 model B with 1 MB of memory and 400 MB of disk. They 
had approximately S/36 devices. About 10 of those devices were running an inquiry program 
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that wasn't too hard on the processor, but we still had many interactive programs and batch jobs 
running throughout the day. Our configuration on the AS/400 was a Model B30, (a big savings 
over the B40 in hardware & software) with 1.7 GB of disk,and 12 MB of RAM. You can never 
have enough memory on the AS/400. We use about half of our disk, and all programs run great 
in the S/36 environment (except #GSORT, that kills the whole system). Prices can only go lower 
on the AS/400, so it might be worth going with the B30 for now, and then justifying an upgrade 
to the B40 a year or two later when prices are sure to be more stabilized. 
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Selected from DataNetwork's electronic bulletin board, TELEFORUM 
From: R. S. of Encinitas, CA To: All 

On the AS/400, is there a way to terminate called programs from the calling program? I have an 
interactive program that calls another program. If the called program uses FI2 to return to the 
caller and then F3 is used from the caller, the called program remains active. I would like to keep 
the called program active until F3 is used from the called program or the calling program. 

From: E. M. of Torrance, CA To: R. S. of Encinitas, CA 

You don't say what language you're using, so I'll assume it's RPG-M. The way to end the called 
program is with the FREE operation in the C-specs of the caller, or simply SETON LR within 
the called program. 

The FREE operation has the following format: 

1. You may condition it with indicators. 

2. Factor 1 is not used. 

3. The Op-code is FREE. 

4. Factor 2 must have a literal with the name of the program, or an alphameric field containing 
such name or the program and library name (or library list). Ex.: The field could have 
'PRGM1ALIBL' (System/38 or S/36 with RPG-III) or '*LIBL/PRGM1' (is this true?) on AS/400. 

5. The LOW resulting indicator can have an optional indicator that will turn ON if there is an 
error return from the called program. 

Since you want to stop the subprogram if F3 is pressed, I guess you could condition the FREE 
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statement with KC. 


On the other hand, the called program will stop itself automatically if you SETON LR in the 
called program prior to RETRN. 

From: R. S. of Encinitas, CA To: E. M. of Torrance, CA 

Thanks for the response. Being new on the AS/400, a word from an experienced person can save 
a lot of time. I used the FREE operation and it seems to do the job. However, there was one 
additional consideration. The FREE operation does not close files or unlock data areas. 

Therefore I need to figure out how to close the files opened by the called program. 

I experimented with Factor 2 and found that the AS/400 didn't like '*LIBL/program' or 
'*CURLI B/program'. 'library/program' or just plain 'program' worked OK. 
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Selected from DataNetwork's electronic bulletin board, TELEFORUM 
From: A. T. of Spotswood, NJ To: C. P. of San Mateo, CA 

I've used your article, published in the February 1989 DataNetwork issue, quite a lot when 
converting 3 files to externally-described, and it has been a great help. One question: In your 
article you wrote that after the new file is created, a program must be written to move the data 
over to the "shiny-new externally described file." A co-worker attended a week-long session in 
Rochester about the AS/400. His lab materials say that using a CPYF (Copy file) command, and 
specifying *REPLACE for the Add or Replace, records moves the records. We are going to try it 
out tonight. Also, you say not to use filler fields in external files. If you are converting programs 
over little by little and wish to keep both RPG/II and RPG/400 programs operating at the same 
time using the same files, filler fields would have to be incorporated into the external-files so that 
the old would still find their data in the old from-to positions. 

From: C. P. of San Mateo, CA To: A. T. of Spotswood, NJ 

You've probably used the CPYF by the time you read this. I guess you can use the CPYF to go 
from internal to external, if the data fields are in the same order, have the same lengths and 
attributes (packed or zoned). The parameter on CPYF to accomplish this is 
FMTOPT(*NOCHK). This will cause CPYF to do a byte-to-byte copy. As best as I can recall, I 
said you should write a one-timer if you have made any changes to data, such as splitting a 
packed MMDDYY field into separate components. You're right about using fillers if you want to 
continue using old programs with the files. But if you are creating brand-new files and programs, 
I don't think you'd want to include fillers. That is, there is no need to "pad" records with blank 
space for future expansion, etc. 
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Selected from DataNetwork's electronic bulletin board, TELEFORUM 
From: J. L. of Los Angeles, CA To: All 

I recently wrote my first RPG/400 print program — a simple read & print deal. I normally use 
"PRINTER" on my F-spec to assign a printer name. It compiled OK, but when I run it, it says it 
can't open file "printer". I changed PRINTER to QSYSPRT, recompiled, and it ran fine. What 
gives? 

From: C. P. of San Mateo, CA To: J. L. of Los Angeles, CA 

Jim, every file used in a program has to exist on the system at execution time. This applies to 
both externally and regularly defined files. So, since your program couldn't locate a file named 
PRINTER on your system (well, in your library list) it complained about it. 

QSYSPRT is defined in the system; you can do a WRKOBJ command and see that. Also, 
DSPFD will tell you all of the attributes of QSYSPRT, which are, mainly, 66 lines x 132 
positions, line 60 overflow, etc. 

You can create your own non-externally defined printer files with the CRTPRTF command. 
Leave the source file/library blank, give it a record length, and fill in the rest of the parameters as 
needed. For example, you might want to create a printer file for CHECKS, INVOICES, etc., 
each having their own forms length, number of positions ... 

When you really get into it, you can start creating externally defined printer files, which use 
DDS. It seems to be kind of a toss-up, using one or the other, but I guess I lean more towards 
externally defined printer files nowadays, since all the other files are external, too. 
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Selected from DataNetwork's electronic bulletin board, TELEFORUM 
From: A. T. of Spotswood, NJ To: All 

We have an AS/400 with a Decision Data UPS (actually manufactured by RTE/Deltec) and 
would like to automatically power down the system in the event of a power failure. I have the 
necessary cabling to the AS/400, so my problem is with the CL program. I can monitor for the 
Message that is sent to my UPS message queue with the MONMSG command, but how do I 
make the program "wait" for that message without using a goto/loop setup? My CL Program 
would have to look something like this: 

PGM 

MONMSG MSGID(CPF1816) 

EXEC(LABEL+ 

(GOTO POWEROUT)) 

Some sort of command that 
just "hangs out here 
waiting for the message?" 

LABEL POWEROUT 
SNDBRKMSG *allws 'Signoff' 

My CL Programming is learned from the book and I've been doing it now for about 3 hours. 

How do I monitor for a message without actually running a program? 

From: C. P. of San Mateo, CA To: A. T. of Spotswood, NJ 

According to the "Backup and Recovery Guide" (SC21-8079), on pages 7-10 and 7-12, a loop of 
some sort is required. Instead of doing a MONMSG, do a RCVMSG, using a WAIT time of your 
choosing (maybe 30 seconds, maybe 120 seconds... up to you). When the program does the 
RCVMSG (after the timer expires), then you check to see if you have the CPF1816 message. If 
you do, proceed with the rest of the power down program. If you haven't received that message, 
loop back to the RCVMSG command, and start waiting again. 

From: M. D. of Van Nuys, CA To: A. T. of Spotswood, NJ 
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Apart from the other message you received on this problem, have you thought about putting this 
CL program in an Autostart job for your Controlling Subsystem or if you don't want to go that 
far at least put it in an initial program for your system operator? 

From: A. T. of Spotswood, NJ To: C. P. of San Mateo, CA 

After leaving this message I took some manuals home for the weekend and happened to find the 
section you talked about. 

It's amazing, though, how this machine is only a "baby" and you seem to be an expert. Thanks 
for your reply. One added item, set your system-value "QUPSDLYTIM" to *NOMAX, 
otherwise any user-supplied UPS program will be ignored. 

From: C. P. of San Mateo, CA To: A. T. of Spotswood, NJ 

I'm just lucky, not an expert. I was able to start working with S/38's back in 1980, and quite a bit 
of it is the same on the AS/400. However, I have practically no experience with the S/36 
environment on the AS/400, so I've been following the board closely to see what I can leam. 
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It's a new day for SAA 

On May 16th, IBM announced the delivery schedule for its new SAA OfficeVision software 
product. IBM touted this announcement as its major offering for the year, on a scale of 
importance equal to that of last year's AS/400 hardware announcement. This is because 
OfficeVision represents the first software product released by IBM which has been engineered to 
all the design points of the Systems Application Architecture (SAA). 

For over two years now IBM has been preparing us for SAA, through various announcements of 
standards, published specifications, and active participation with software houses in every 
spectrum of the industry. For most of the programming community, SAA has seemed a bit like 
IBM's new holy grail: years ago it was Systems Network Architecture (SNA), then, during the 
clone wars, it was Document Content Architecture. SAA seemed like one more fuzzy acronym to 
tack on the wall, with little or no long term effect on the underlying operation of systems. Data 
processing was still going to be data processing, no matter what combination of letters IBM 
chose to call it. 

However, OfficeVision portends to change all this and if IBM is successful at meeting its 
ambitious timetable for delivery, this next year will be a watershed for data processing 
departments. After the implementation of Office Vision — through the OS/2 Presentation 
Manager — expectations placed upon DP professionals will never be the same again. If it was 
hard to compete against Personal Computers in the past, its going to be torturous in the 
immediate years to come. Why? To understand, you will have to see Office Vision on OS/2 
Extended Edition's Presentation Manager. 

The key to the OfficeVision product is the OS/2 Presentation Manager, which looks much akin 
to Microsoft Windows or the Macintosh environment. The screen is represented as a "desktop" 
with various "Icons" placed informally across the display. One Icon represents "Electronic Mail", 
another "Calendaring", a third "Word Processing." There are "IN" basket Icons, and "Out" basket 
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Icons. Data is represented as "File Cabinet" Icons, and there is even a "Shredder" Icon, in the 
event that you have something important to send to Oliver North. 

Applications are activated by a pointing device, such as a mouse. Once activated, a window 
expands, allowing the user to gain access to the controls of the application itself. Multiple 
windows may be activated simultaneously, and the user may cut and paste between applications 
at will. All in all, OfficeVision looks, feels, tastes, and operates exactly as one would expect in 
the millennium since the introduction of the Macintosh. Such was, after all, the specification of 
the Common User Access of SAA - a Mac-like interface that is easy to use. 

But the revolutionary impact of OfficeVision is its band-width. OfficeVision does not simply run 
on a PS/2 under OS/2 Extended. It also runs on a 9370 under MVS or VM, or an AS/400 under 
OS/400. Instead of relying upon a single architecture, it can and will make use of all of IBM's 
product line, building upon the multiple strengths of IBM's complete network of computers. 

The high-end PS/2 OS/2 Programmable Workstation provides the interface to tie together all the 
individual functions of OfficeVision, and to integrate these functions with other micro, 
midrange, or mainframe applications. This means that a payroll application on a mainframe in 
Dallas can be represented as its own Icon on the PS/2 Workstation in Fresno. 

More importantly, the integration capability of OfficeVision was demonstrated during the 
announcement with a variety of third party software. The CEO's of these products were 
introduced during the announcement, and time was provided for their own comments about the 
significance of the OfficeVision product. Microsoft, Lotus, and others — including mainframe 
and midrange developers — were well represented. Each executive told the same story: 

OfficeVision and SAA are the key to their strategies in software development. 

SAA Office Vision is also coupled with an aggressive delivery schedule. Beginning in 
September of this year, OfficeVision will be shipping Release 1 versions, and moving to Release 
2 across the entire product line by June of 1990. This highly accelerated delivery schedule 
indicates that IBM has every intention of keeping the product current and synchronized 
throughout its offerings. 

How the implementation of this announcement will effect S/3X and AS/400 Managers will be 
interesting to watch over the next year. There is already a rarefied atmosphere in these shops, 
after the record deliveries of AS/400's of 1988 and 1989. Indeed, some System/36 managers 
have likened the atmosphere to the euphoria experienced after a funeral wake: they know their 
platform is limited, yet have been unable to create the business reasons to move their 
organizations beyond the System/36. 

At the same time these same System/36 shops are undergoing traumatic personnel displacements 
as programmers look for opportunities to move onto the platform of the AS/400. This industry 
turmoil is heightened because several areas of the country are experiencing a shortage of AS/400 
or System/38 trained professionals. This shortage is even dislodging personnel from the 
established System/38 shops as programmers gamer for the premiums of better pay. What the 
industry is witnessing is a significant shift of professionals as they try to line up their skills with 
the careers laid out for them by IBM. 

Now, as IBM adds the power and the performance of the OfficeVision interface to the new SAA 

Next 


Home 


Previous 








applications this year, it would seem likely that even more turmoil is ahead. OfficeVision may 
give many S/36 shops the final argument that has been missing: the argument which 
demonstrates to management the functional advantage of the AS/400 over the S/36. OfficeVision 
is impressive enough to convince even die-hard CEO's that change is in the wind. Observing this 
change and its effects on the stalwart System/36 industry will be an interesting spectacle. Though 
IBM has promised to support the S/36 for several more years to come, the promise of 
OfficeVision may make the longevity of SSP both insignificant and academic. 
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It's simple to display a menu of alternative programs from a program 

Phone directories, note pads, to do managers, online calculators, message systems ... these are 
the kinds of programs that users often require instant access to throughout the day. Global 
commands or menus are effective for job initiation when you can get to the command line, but is 
there a quick and easy access path to such programs while engaged in another interactive job? 

Without proper planning, your users must rely upon their own talents to interrupt and 
recommence programs. As you know, it is not advisable to leave anything up to the user that you 
can take care of automatically. Therefore, it is your responsibility to provide a safe and speedy 
roundtrip passage to the alternative program and back to the primary program. 

With the technique and sample program featured in this article, your users will be able to press 
the attention key to pop up a menu of their most commonly used alternative programs instantly. 

The menu of options is an opaque window that displays over the current screen. Selecting a 
menu option will run the related program. When finished with the alternative program, F3 
returns control to the primary program at the exact point it left off. 

How It Works 

Normally on the AS/400, nothing happens when you press the attention key. 

Setting the "Attention Key Handling Program" with the Set Attention Program (SETATNPGM) 
command can change this. The attention key will initiate any program that SETATNPGM 
specified. 

Likewise, you can set the program for a particular user with the ATNPGM parameter in the user 
profile. If you have not set a program with either method, the attention key is inactive. 

Generally, pressing the attention key on an unlocked input-ready keyboard will interrupt the 
current job, save the display, and call the Attention Key Handling Program. 
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For our pop-up menu technique, you must set the Attention Handling Program to POPMNU. 

This program displays a list of menu options that is set up in the CHGVAR statements of the 
POPMNU CL program. When the user selects an option, POPMNU calls the specified program. 
The ASSUME keyword in the display format causes the display file to overlay the current screen 
rather than erase it. Furthermore, the RSTDSP(*YES) parameter of the Create Display File 
(CRTDSPF) command saves the current screen data when the program opens the display and 
then restores the data when the program closes the display. 

The SETATNPGM command in POPMNU is optional. If used, the user can press the attention 
key while in an attention key program. This will allow you to go deeper into sub-levels of 
attention key programs. The problem with this is that you could easily get lost and forget that 
you have other programs in the program stack. Also, you will have problems if an RPG/400 
program calls itself or a program that is higher in the invocation stack. 

You can execute POPMNU from the Resource library functions display to give you an idea what 
it looks like. None of the options are functional; they are only there for illustration. After you 
copy the source members from Resource library into one of your own libraries and modify them 
for your needs, you can make it your attention key handling program. 

SETATNPGM PGM(library name/POPMNU) SET(*ON) 

You can key this in at the command line, or more appropriately, set it on and off (*OFF) from 
within a particular interactive job. It remains in effect until the user signs off or issues another 
SETATNPGM. If you've set the Attention Key Handling Program in the user profile, it will 
remain on unless overridden by a SETATNPGM command. 


Figure 1 CL program POPMNU 


POPMNU: + 

PGM 

DCL VAR(&ATRCHR) TYPE(*CHAR) LEN(l) VALUE(X'22') 

DCL VAR(&ENDCHR) TYPE(*CHAR) LEN(l) VALUE(X'20') 

DCLF FILE(POPMNUDF) 

/* The following line should be de-activated if you do not want + 
to set the attention key program to more than one level */ 


SETATNPGM PGM(POPMNU) 
CHGVAR VAR(&FLD001) + 
VALUE('._ 


') 


VAR(&FLD002) 

VALUE('| 



- 

VAR(&FLD003) 

VALUE('| 


ATTENTION MENU 

- 

VAR(&FLD004) 

VALUE('| 



- 

VAR(&FLD005) 

VALUE('| 

1 . 

Personal Notepad 

- 

VAR(&FLD00 6) 

VALUE('| 

2 . 

Personal Calendar 

- 

VAR(&FLD007) 

VALUE('| 

3. 

S/38 Calculator 

- 

VAR(&FLD008) 

VALUE('| 



- 

VAR(&FLD00 9) 

+ 





VALUE('|_ 


F3-Return 


.1 ') 


CHGVAR VAR(&FLD010) VALUE(' Enter Selection ...') 

CHGVAR VAR(%SST(&FLD003 03 1)) VALUE(&ATRCHR) 

CHGVAR VAR(%SST(&FLD003 38 1)) VALUE(&ENDCHR) 

DISPLAY: + 

SNDRCVF 

IF COND(&IN03 *EQ '0') THEN (DO) 

IF COND(&SINP *EQ '!') THEN(CALL PGM(NOTEPAD)) 
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IF COND(& SINP *EQ '2') THEN(CALL PGM(CALENDAR)) 
IF COND(&SINP *EQ '3') THEN(CALL PGM(S38CALC)) 
GOTO CMDLBL(DISPLAY) 

ENDDO 
ENDPGM: + 

ENDPGM 


Figure 2 Display file POPMNUDF 


Create Display File with RSTDSP(*YES). 
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To a considerable degree, the title of this month's installment of the AS/400 Database saga is a 
miscue. Most of what follows here is not about how to use the AS/400 Database in System/36 
mode. Instead, the hot topic is how new migrants to the AS/400 from the System/36 can avoid, 
as much as possible, having to use System/36 mode in the first place. 

SPEED BUMPS 

The main reason for wishing to avoid the System/36 mode of AS/400 operation is, by now, 
probably known to most of you. The problem, in a word, is speed. System/36 mode on an 
AS/400 is widely reputed not to have any. 

The users and consultants I have talked to assure me that this speed problem is quite real. I have 
found no one with AS/400 conversion experience from a System/36 who thinks that the new 
machine's performance in System/36 mode measures up — pound for pound — to a real 
System/36. You should not, therefore, plan on running any of your existing applications in the 
AS/400's System/36 mode over any long term. 

ONE UP 

The dimensions of the speed problem are not absolutely cut and dried. But there is a cynical- 
sounding rule of thumb going around in IBM midrange computing circles in this part of the 
world. Briefly, that rule of thumb goes as follows: If you plan to run migrated System/36 
applications in System/36 mode on your new AS/400, you can select a suitable machine by going 
through all the computations IBM recommends for sizing an AS/400 equivalent to your 
System/36, then going up one model number. If the numbers say you need a BIO, in other words, 
you really need a B20; if the numbers say B40, order a B50. 

A performance shortfall of this magnitude is no small matter. The price of an AS/400 system unit 
goes up appreciably for each model number increment, of course. But, still worse, so does the 
price of every IBM-supplied software product. A substantial additional outlay is required to 
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obtain an AS/400 having enough horsepower to run minimally-converted applications in 
System/36 mode with acceptable speed. 

The amount of this additional outlay might well be more than it would cost to perform a more 
comprehensive conversion process on your applications — one that would allow them to execute 
in AS/400 native mode. In addition to directly migration-related savings, your future new 
application development would also benefit if added to existing applications that were better 
aligned with the architecture of the AS/400 than are most System/36 applications. 

OVERHEAD 

The reported molasses-like performance of the AS/400's System/36 mode, then, is a genuine 
misfortune. IBM obviously went to considerable trouble to produce an execution environment 
for the AS/400 that could, except for a few unavoidable details, mimic the operation of a 
System/36 — a very different machine. 

The idea was to provide migrating System/36 users with an "effort buffer." This would allow 
them to convert application logic and file designs to take advantage of native AS/400 capabilities 
at a self-chosen pace. The hardest part of any machine conversion is accomplishing the high peak 
programming workload imposed by the usual requirement that all migration changes have to be 
made at once. Under the AS/400's System/36 mode, migrated applications could continue 
running on a more or less business as usual basis until the poor, harassed programmers — that's 
you — could get around to converting them to AS/400 native operation. 

Being able to do your conversions in a phased way — instead of in one big, spasmodic rush — is 
an attractive idea. You might even be able to do your own conversion that way, at least in part. 
But the significant speed penalty exacted by IBM's implementation of System/36 mode on the 
AS/400 makes it expensive to take it too slow and easy. 

TRIAGE 

When medical personnel are faced with a sudden catastrophe that produces large numbers of 
victims — a Beirut Marine barracks, an Armenian earthquake, a Tien An Men Square massacre — 
they begin treatment by performing triage (TREE-ahj). Those still alive are quickly examined 
and sorted into three groups based on probability of recovery. In the first group are the ones who 
are goners no matter what. They are set aside to die. In the second group are the lightly wounded. 
They can be attended to later, so they too are set aside. In the third group are the seriously 
injured who can still be saved by prompt treatment. Doctors and nurses concentrate on trying to 
save these first. 

SOFTWARE TRIAGE 

You should probably begin a System/36-to-AS/400 migration by doing a kind of triage on your 
application software. Software modification, like medical treatment, is labor intensive, skilled 
work. A machine conversion, like a major disaster, requires that a lot of work be done in a short 
time. In neither case does it pay to waste effort. 

Your software, of course, is not "injured" in the way an accident victim or battle casualty is. But 
software does vary in terms of relative time-urgency for conversion when a move to a new 
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machine is underway. 

MOST CRITICAL 

The most conversion-critical software is whatever runs routinely, every day or almost every day. 
Included would be any major on-line systems that support your company's business in real-time, 
plus any on-demand queries or reports that are frequently called. 

If your company's application load is typical, you will find that the software meeting these 
descriptions includes almost all code that adds to, changes or deletes from the master files and 
principal transaction files on your system. 

Realistically, you have to have all of this software converted as a unit to run on your new 
machine. This means your conversion efforts, at least for this most critical part of your installed 
application base, will have to be done in advance of moving any live production onto the new 
machine. Once the most frequently used code is squared away in its new form, you can move 
over and/or convert up-to-date production files from the System/36 to initialize the AS/400 for 
live operation. 

LESS CRITICAL 

Corresponding to the patients with bumps, bruises and superficial flesh wounds will be all parts 
of your application systems that don't have to be run more often than, say, once a month. Many 
applications, especially financial and accounting applications, have cyclicality built into them. 
There is often a lot of report generation, in particular, that is set to occur on or about monthly 
intervals. 

The least critical application code, then, is that which runs at intervals of more than a month. In 
terms of quantity, this is likely to be the smallest of the three categories into which you should 
divide your software on the basis of its frequency of use in production. 

SCHEDULES AND DEADLINES 

Converting your most-frequent-use application code is likely to be the most varied and extensive 
part of the migration job. Doing the converting must take as long it takes, obviously, but machine 
conversions should have definite endpoints. Production on the new machine should commence 
as soon after delivery as possible, and the system migration process should wrap up as quickly 
after this start of production as possible. 

One way to telescope the migration schedule somewhat is to launch production with the 
converted most-frequent-use code as soon as it has proven itself in tests, then work on converting 
the monthly or less frequently needed code with the idea of having these items cut over in time 
for their next needed use. 

Inaugural AS/400 production, using your freshly converted and tested most-frequent-use code, 
should begin the day after all the month-end cyclical stuff runs for the last time on your 
System/36. In this way you give yourself the following full month to get month-end code 
converted and operating on the new machine. A second month ought to be enough time in which 
to convert any remaining odds and ends that are even less time-critical than the monthly reports, 
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etc. 


THE NATIVE QUESTION 

With a plan for what software to convert, and in what order, the next thing to settle is what 
conversion ought to consist of. Here we get into the opening rounds of an almost theological 
argument about what really constitutes "native" application code for the AS/400. 

An application that can compile and run on an AS/400 in the native environment is a "native" 
application in at least a trivial sense, but not in a useful sense. The usual implication of the 
phrase "native code" is that an application thus described has been designed to take advantage of 
one or more of the unique features that comprise the AS/400 software environment. Any 
application built without reference to such features, then, is definitely not native. In this way, 
then, native code has a negative as well as a positive definition. 

These definitions suggest what we also seem to feel intuitively — that "nativeness" is less an 
either/or proposition than it is a matter of degree. If application A, for example, uses more of the 
AS/400's unique features than application B, then A can be said, in some real sense, to be more 
native than B. This is pretty much the viewpoint taken in subsequent sections of this article that 
deal, specifically, with various identifiable aspects of nativeness in applications design. 

COVER CHARGE AND MINIMUM 

There is one more aspect to the nativeness question that bears comment. In the commonly 
accepted use of the term it is not just necessary that a native application embody at least one 
specifically AS/400 feature in its design, but that a particular feature be employed. The minimum 
level of acceptability demanded of an application with a pretense to native status is that it employ 
file, record and access path definitions coded independently of the programs that reference them 
through use of Data Description Specifications (DDS). 

The use of externally described files, as they are called, has come to represent the minimum 
acceptable standard of nativeness for AS/400 application code for a good reason. The central 
feature of the AS/400 is its underlying, indeed inescapable, database management system 
(DBMS). No application can take full advantage of that DBMS if its data definitions are made by 
the programs rather than by DDS. No files not defined by DDS can be fully — or even minimally 
— used in conjunction with any AS/400 query processing facility, for example. 

As we shall see, an application can definitely exhibit more nativeness than just use of externally 
described files. But it must come up, at least, to this minimum standard if it wants to fly the 
native flag. 

ONE FOR ALL AND ALL IN ONE 

Minimally acceptable nativeness, of course, is exactly what you do not get in applications pulled 
straight across from a System/36. You should keep in mind that externally described files do not 
suddenly appear when you use IBM's Migration Aid. The Aid helps you organize things on the 
System/36 side, then copy and transfer them to the AS/400 side, but the applications thus moved 
are fit to run only under the AS/400's System/36 Execution Environment. 


Next 


Home 


Previous 








Files used by applications running in the System/36 mode are, like all other files on an AS/400, 
actually created and manipulated via the AS/400's DBMS. At the DBMS level, these files also 
obey the only-one-record-format-per-file rule. But there is a layer of disguise standing between 
the actual AS/400 DBMS facilities and System/36-style application code. 

Creating the illusion of files with multiple record formats — as allowed by the System/36 — is not 
hard for the AS/400's System/36 mode. System/36 applications don't employ external file and 
record definitions. All such definitions are made with input and output specs in RPG programs, 
or comparable language features in COBOL or BASIC. The underlying physical database files 
are defined to the AS/400 DBMS as having only a single big alpha data field. 

Each program in a System/36 application imposes its own field-level definition on such records 
as it runs. The AS/400 DBMS sees only program-prescribed manipulations to the bytes of a 
single big field no matter what record type the application program understands itself to be 
working with. 

LET'S PRETEND 

For files that have to look as though they have more than one System/36-style index, there is a 
comparable disguise at work. An underlying AS/400 physical file is defined with enough 
separate fields to allow all the System/36-type alternate keys to be specified. The alternate keys 
are defined as AS/400 logical files. Groups of AS/400 physical and logical file definitions, 
therefore, are made to look like single files with multiple indexes to accommodate the logic of 
migrated applications. 

GHETTO 

One of the main advantages of a database-oriented system such as the AS/400 is that new 
applications can be built using some or all of the data file contents originally designed for other 
applications. To actually exercise this advantage, though, the files in question have to be defined 
to the DBMS down to the field level. If the records are just big, undifferentiated lumps, you 
might as well go back to using a conventional file system. If your fields are program-defined 
based on relative position in one of those big undifferentiated lumps, in fact, you more or less are 
using a conventional file system. 

"Dumbing down" the AS/400 DBMS by not telling it where the fields are condemns all the fields 
in strictly program-defined record formats to invisibility as far as new applications that use the 
full power of the DBMS are concerned. This is particularly true with respect to the powerful 
query components of the AS/400 DBMS. These absolutely have to know about fields in order to 
do their thing. 

In order to be a full citizen of the new AS/400 world, an application from the System/36 "old 
country" has to "learn the language," so to speak. That "language" is database management. It is 
based squarely on the equation "I'll show you my fields if you'll show me yours." 

PLOWING FIELDS 

In other words, those System/36 applications are going to have to join the rest of the AS/400 
world some time. Why not make it sooner instead of later? You have gotten your applications 
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across the System/36-to-AS/400 chasm and deposited them safely on your DASD, albeit still in 
System/36 trim. Now you need some kind of magic wand to wave that will produce externally 
"compilable" DDS corresponding to all those program-defined files. 

To do this without expending lots of time in error-prone tracing of file and field relationships by 
hand, IBM now offers something with the lyrical name of 'AS/400 Programmer Tools PRPQ 
5799-DAG.' The tool in question does quite a lot, but one of its central functions is to trace 
through System/36 OCL and System/36-type RPG II and do the program-defined-file-specs-into- 
DDS trick. On the way to performing this application makeover, it also tips you off any time 
there is an ambiguous file reference or field definition in your code. If a field is sometimes alpha 
and other times numeric, you'll hear about it. 

ZERO IS ZERO, BLANK IS BLANK 

This type of cleaning process is valuable for another reason — avoiding run-time field content 
errors. One of the nice features of the AS/400 is that, Santa-like, it keeps a list and checks it 
twice before it does most anything — even add two numbers together or edit one for printing. 

The downside of this is that the AS/400 is not as "loose" about certain data representation 
ambiguities as the System/36 and its ancestors were. If a file record has blanks in a particular 
field, for example, the AS/400 will refuse even to read that field if something numeric was 
expected instead. System/36's routinely produce such situations by creating new records using 
program code that does not define, or set to proper defaults, all intended fields of a given record 
type. 

Among other things, this means that your System/36 data files need to be carefully "cleaned" of 
any blanks in numeric field positions before you load them onto your AS/400; the new machine 
won't appreciate the humor. Once your System/36 application code has been converted to 
external DDS file and record definitions, this type of thing won't happen anymore if you have 
been careful to specify proper default values for all defined fields. 

OCL? OH, CL! 

While not strictly database related, the burden of converting System/36 OCL procedures to 
equivalent AS/400 CL also hangs over anyone wanting to skip their System/36 applications over 
the AS/400's System/36 mode and go directly to AS/400 native operation. 

IBM recommends a two-step process. Lirst, you use the IBM System/36 to IBM System/38 
Conversion Aid (Item 5714-CV9) to translate System/36 OCL to System/38 CL. Second, you hit 
the generated System/38 CL with the AS/400 CVTCLSRC (Convert CL Source) command to 
translate everything into the somewhat revised syntax — and occasionally revised keyword 
commands — used on the AS/400. 

Even with all this mechanical assistance you may still have some small bits of business to attend 
to by hand. There will almost certainly be some optimization and streamlining you can do to the 
generated CL with a bit of judicious editing. The important thing is to automate the bulk of the 
donkey work involved in making such a conversion. 

RESUME SPEED 
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Having generated both DDS external file descriptions and AS/400 CL for a formerly System/36- 
based application, that application can now be called native with a straight face. It is worth 
mentioning, though, that you may legitimately wish to do the CL step first in order to render the 
application more or less immediately capable of running under the AS/400's normal environment 
instead of the lethargic System/36 mode. 

In addition to the OCL-to-CL conversion that is needed, a few additional modest coding changes 
are likely to be required in the programs themselves. The detailed considerations involved in 
doing one of these "Speed First, Native Later" conversions were spelled out in "Converting RPG 
II to Native RPG", DataNetwork, December 1988. 

If you do elect to convert System/36 applications into this full-speed-runable form, you will still 
need to keep the source code of the migrated System/36 versions around for a while. The PRPQ 
Programmer Tool that helps you generate external file definitions needs System/36 OCL to chew 
on. 


OUT OF SORTS 

Ascending further up the evolutionary scale of "nativeness," you might next move to eliminate 
sorting as a factor in your migrated applications. This definitely crosses the line from being 
strictly a necessity of conversion to being a retrofit step, but it is comparatively low-effort as 
retrofitting goes. 

Report production logic seems to account for the vast majority of sort activity on System/36s. 
The logical file facility of the AS/400 DBMS allows a generally better approach. You can 
specify indexes capable of serving up file records in almost any desired collation order. 
Include/omit specifications can be worked in too; everything is spelled out in the DDS defining 
the logical file. Sorts, therefore, can be replaced with logical file definitions. Report programs 
just read records via a suitable logical file instead of directly from a sorted file. This has the 
added benefit of simplifying the needed CL coding. 

THE URGE TO MERGE 

Replacing sorts is also more machine-efficient — at least in most cases. By specifying delayed 
maintenance for a logical file's access path, you avoid any response time penalty for on-line 
processes that add, modify or delete records in the file over which the logical file is defined that 
will later be accessed to produce a report. All pending maintenance to said access path gets put 
off until you fire up the report program and open the logical file. 

To sort a file, all of its records have to be passed at least once to do include/omit, then the 
remainder have to be sorted and merged. A logical file with delayed maintenance specified, 
though, can just do an incremental include/omit pass, sort just the applicable changes that have 
stacked up since last time, then merge them into the existing index structure. Unless a third or 
more of the logical file's key values have been changed in the underlying physical file, this 
should take less time than sorting everything from scratch. 

DI-WRECKED FILES 

One more notch up the native scale is another retrofit step — elimination of direct files. When 
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you think about it, access to file records by relative record number is not what a business 
programmer ought to have near the top of his or her wish list. A file system or DBMS that allows 
multiple, customized indexes into any file is far more desirable. 

A few sharp System/36 coders have used direct file access to build custom access methods in 
RPG. Many more use relative record number accessing in certain situations to improve 
application speed. For this reason, many System/36 heavyweights have gotten it into their heads 
that direct files are a "must-have." 

The AS/400 DBMS, though, provides accessing capabilities more sophisticated than even a very 
competent programmer can construct with System/36 direct files. Even more important, the 
fundamental differences in the way the AS/400 handles file allocation and indexing make it 
unlikely that access by relative record number can improve on the speed of indexed access in 
most situations. Just as logical file definitions can replace sort specifications, you will find they 
can make direct files and record number access tricks obsolete, and for the same reasons. 

LOGICAL 

Logical files, in fact, solve a great many problems. Ratcheting up the native scale by a third 
notch, you should normalize the file definitions of your migrated System/36 applications if this 
was not done at design time back on the System/36. You can minimize the impact of file 
normalization on your application logic by using logical files, multi-format logical files and even 
join logical files to synthesize records similar to the ones these applications were originally 
written to process. 

PUTTING HUMPTY-DUMPTY TOGETHER AGAIN 

A fourth incremental move toward nativeness is to recombine System/36 applications that 
consist of multiple programs only in order that each can compile into 64K-bytes or less. Such 
programs typically interface heavily via the local data area (LDA) or even through the use of 
single-record direct files. 

The AS/400 has, for all practical purposes, no upper limit on program size. Also, its virtual 
memory architecture should result in many fewer disk accesses to load program parts when one 
large program can perform an entire job, rather than when numerous smaller programs are 
constantly "handing off" to one another, terminating and then reloading. 

In contrast to this, functions that are used in several programs should be extracted and made into 
programs of their own. These new multi-use programs will then be CALLed from their parent 
programs. 

SCREENED 

A fifth jump up the nativeness scale is the use of subfiles to process screens that have a scrollable 
area in which each of several lines holds fields from a different record in a given physical or 
logical file — scrolling through the line items of an invoice, for example. 

This is not really the place to go into a long-winded explanation of subfiles and their uses. 

Suffice it to say that subfiles are a kind of logical entity supported by System/38s and AS/400s, 
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but not by System/36s. Scrollable multi-record displays were certainly possible on the 
System/36, they just had to be handled in a different and more difficult way. 

SUMMARY 

You will find, then, that migrating applications from a System/36 to an AS/400 is not an entirely 
cookbook process, even though a lot of useful automated assistance exists. The low performance 
of the AS/400's System/36 mode of operation places a premium on planning any application 
migrations so as to leapfrog System/36 mode entirely and go directly to AS/400 native mode 
operation. Migration, though, is itself a process that can shade gradually into full-blown software 
retrofitting. Finally, you should now see that "native AS/400 code" is a term that describes a 
continuum of things, not a single thing. 

Next month we will start our look at what IBM has got inside the AS/400 software box labeled 
'SQL.' 
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When you modify a command by adding or deleting a parameter, or changing a parameter's 
attributes, you may need to change some or all of the CL programs that call the command. But 
what if you don't recall the names of all these CL programs? The PRTCMDUSG command 
comes to the rescue by spooling a list of all CL programs that use the command in question. In 
fact, you can specify up to fifty commands on which to search. 

Note: Any HLL programs that executes a command by calling QCMDEXC will not be listed. 
DataNetwork Staff 
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I have a couple of tips for those concerned with saving space on the AS/400. 

First, if a program does not need to be debugged in the near future, you can "Remove 
Observability" information to drastically reduce the size of the program. You do this with the 
Change Program (CHGPGM) command, using *YES for the Remove Observable info 
(RMVOBS) keyword. You can remove observability for one program, several programs, or all 
programs in a library. 

Second, whenever you compile a program, the system automatically places the old version of the 
program into QRPLOBJ library. These old objects are saved in case a user is attached to the 
object. QRPLOBJ is cleared at each IPL, but if you do not perform IPL's very often, QRPLOBJ 
can get very large. A shop that does not IPL often an does a lot of programming should 
occasionally clear (CLRLIB) or delete (DLTLIB) QRPLOBJ. If you delete it, it will 
automatically rebuilt during the next IPL. 

From Phil H. Kestenbaum Teaneck, New Jersey 
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The AS/400 has a terrific utility that hasn't received much press. With it you can quickly update 
any field of any file without having to first write a custom program or manually create a DFU. 
The Update Data (UPDDTA) command will automatically create and begin a DFU update 
program that will include all the fields in the file. It takes just a moment for UPDDTA to build 
the program from the DDS specifications. No matter if the field is alpha, packed, binary, or 
zoned-decimal, any field defined in the DDS will be displayed. 

Only use UPDDTA if the file is defined by DDS. If it is not, it will still compile an update 
program for you, but there will be one large alphanumeric field for the entire record. This, of 
course, spells trouble if you have any packed or binary data in the record. 

UPDDTA can also be called in PDM's "Work With Objects" display with option 18. 

DataNetwork Staff 
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Option 14 of PDM's "Work With Members" screen is used to compile a source member. 
Programmers primarily use it to create objects from RPG, CL and other high-level language 
source code. Likewise, it will also create a physical file from a DDS source member. 

When you execute option 14 against a program source member that has been previously 
compiled, it will replace the existing object with the newly compiled one. But if you run option 
14 against a DDS member for a physical file that already has data in it, you will get more (or 
should we say, less) than you bargained for. 

You'll find that option 14 erases all the data in the DDS member's physical file. This is not 
something you would expect from this often used and supposedly safe option. We are sure that 
option 14 has ambushed many a novice AS/400 programmer in this way. 

The following steps show the proper method of recompiling a DDS definition for an existing 
physical file: 

1. Rename the existing physical file 

2. Create a new file from the DDS specs 

3. Copy (CPYF) the renamed file from step 1 to the new physical file, using the *MAP and 
*DROP parameters in the FMTOPT keyword. 

4. Delete the renamed file 

Since changing DDS specs is something that is done every so often during application 
development, it would be convenient to automate the steps we have listed. We have written a 
command (RCRTPF) and a CL program with the same name that will recompile the DDS specs 
and recreate the file without losing data. 

Key and compile the RCRTPF command and CL program. See Figures 1 and 2 for the source. 
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7RCRTPF or RCRTPF followed by F4 will display a three parameter input screen that will 
prompt you for the DDS member name, the source physical file, and the library in which the 
DDS member exists. 

To make this command especially useful, you can create a two-character user-defined PDM 
option that will pull in the parameters from PDM and not issue the prompt, just like the IBM- 
supplied options. See chapter 5 of the PDM User's Guide and Reference. 

DataNetwork Staff 


Figure 1 Command RCRTPF - Recreate Physical File 

CMD PROMPT('Re-create physical file') 

PARM KWD(PFNAME ) TYPE(*CHAR) LEN(IO) PROMPT('Enter file name') + 

MIN (1) 

PARM KWD(SRCFILE) TYPE(*CHAR) LEN(IO) PROMPT('Enter DDS source file') + 
MIN (1) 

PARM KWD(LIB ) TYPE(*CHAR) LEN(IO) PROMPT('Enter Library') + 

MIN (1) 


Figure 2 CLP for RCRTPF command 


RCRTPF: + 

PGM PARM(&PFNAME &SRCFLE &LIB) 


TYPE(*CHAR) 
TYPE(*CHAR) 
TYPE(*CHAR) 
TYPE(*CHAR) 
TYPE(*CHAR) 


LEN(10) 
LEN(10) 
LEN(10) 
LEN(6) 
LEN(7) 


*CAT &JBNUM) 


DCL VAR(&PFNAME) 

DCL VAR(&SRCFLE) 

DCL VAR(&LIB) 

DCL VAR(&JBNUM) 

DCL VAR(&WFNAME) 

RTVJOBA NBR(&JBNUM) 

CHGVAR VAR(&WFNAME) VALUE('F' 

DLTF FILE(&LIB/&WFNAME) 

MONMSG MSGID(CPF2105) EXEC(GOTO CMDLBL(RENAME)) 

RENAME: + 

RNMOBJ OBJ(&LIB/&PFNAME) OBJTYPE(*FILE) NEWOBJ(&WFNAME) 

CRTPF FILE(&LIB/&PFNAME) SRCFILE(&LIB/&SRCFLE) SRCMBR(&PFNAME) 
MBR(*NONE) MAXMBRS(*NOMAX) SIZE(*NOMAX) 

CPYF FROMFILE(&LIB/&WFNAME) TOFILE(&LIB/&PFNAME) FROMMBR(*ALL) 
TOMBR(*FROMMBR) MBROPT(*REPLACE) FMTOPT(*MAP *DROP) 

DLTF (&LIB/&WFNAME) 

ENDPGM 
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Many who have migrated from the System/36 to the AS/400 have noticed slower display 
response time, especially with workstation programs that use variable multi-line screens. It is 
very possible that the response time can be dramatically improved by a simple modification to 
your display file. 

System/36 $SFGR members migrated to the AS/400 through IBM's Migration Aid software are 
converted to DDS source members. If a $SFGR screen does not use Suppress Input (most don't), 
the converted DDS member will have the keyword INVITE added to the screen. INVITE causes 
a read request at the time of the screen output operation. On the AS/400 this takes a noticeable 
amount of time. In cases where there is no input defined for a screen, the INVITE is not 
necessary. Most variable line screens do not define input, so if you remove the INVITE keyword 
from the converted DDS member, you will notice quite a reduction in the time it takes to display 
multiple variable line screens. 

We tried this on a program of ours that displayed 15 variable lines in a row. We couldn't believe 
the improvement! Instead of seeing one line at a time slowly display, it appeared that the whole 
group of lines was displayed at once. 

Note: System/36 converts can find the converted DDS members in your migrated library in 
source file QS36DDSSRC. After you make modification to any DDS member, use the 
CRTDSPF command to create a new object. 

DataNetwork Staff 
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Selected from DataNetwork's electronic bulletin board 
From: S. C. of Milford, IN To: All 

We are considering using an AS/400 Model BIO for one of our plants. We would communicate 
to a larger AS/400 B40 only occasionally. We would have about three users to start with, running 
in S/36 Environment. Has anyone had any experience with the BIO. How is the performance, 
response times, etc. 

From: R. L. of Mt. Kisco, NY To: S. C. of Milford, IN 

The AS/400 BIO got a bad rep when it was first announced. But, if you feed it enough memory 
(8MB as a minimum) it works fine. Response times are equivalent (or better) to the 5362/5363. 

This should serve your 3 or so users just fine. 

From: B. K. of Roslyn, NY To: All 

We are about to order an AS/400 BIO to use as a learning tool and to help us iron out migration 
problems before we purchase a B50. This model will be later sent to an office in an another state. 

Is there anything we should know about the BIO vs. all other models? Any compatibility 
problems? 

I would like to know how valuable the Q & A data base is through the ECS. If we buy it through 
a third party, we won't have this service (so I have read). But there is a significant price 
difference between the two. Keep in mind that we are a S/36 shop with no experience on the 
S/38, but we do have a top notch in-house development team. The third party is a top notch 
company and we have never had any problems with them in the past with S/36 upgrades. 

From: R. F. of Mt. Kisco, NY To: B. K. of Roslyn, NY 

Don't even consider a 4MB BIO! 
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The on-line Q & A is of dubious value. You'd probably get answers that are just as good and in 
the same time frame from this BBS! As long as you're happy with the third party, have done 
business with them before, and are confident that they will be around in the future, there's no 
reason not to use them. 
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by Openbbs Contributor 

Selected from DataNetwork's electronic bulletin board 
From: D. D. of Harleysville, PA To: All 

We are in the process of ordering an AS/400 Model 50. IBM is configuring 9332 DASD and a 
software vendor is recommending 9335 DASD. What is the consensus as to which is the better 
drive. 

From: R. L. of Mt. Kisco, NY To: D. D. of Harleysville, PA 

The 9332 drive has a smaller aggregate capacity per drive, but its access and transfer speeds are 
higher than the 9335. As a result, the 9335 configured machine may store more data in a given 
amount of rack space, but the 9332 equipped machine will have better response time. 
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From: K. C. of Chestnut Hill, MA To: All 

Instead of using externally defined messages in my DDS source, I want to use a message 
member like I did on the S/36. Can anyone tell me how to get started doing this? For instance, 
how do I first create the message member? How are the individual messages accessed (is it like 
on the S/36 where I put a number in front of it (0001 Invalid Store)? What exactly is the code I 
need to use in my RPG/400 program to display this message? Where do I store this member once 
I am through entering my messages? 

From: C. P. of San Mateo, CA To: K. C. of Chestnut Hill, MA 

Messages are kept in "message files" (object type *MSGF). Use the CRTMSGF command to 
create the message file. Use the ADDMSGD (add message description) command to enter 
messages into the MSGF. The messages are identified as AAANNNN, where "AAA" represents 
a 3 letter alpha identifier, NNNN is a four digit number. IBM suggests that you start the "AAA" 
with the letter "U" (to designate "user" type messages, I suppose). 

You can display and get a listing of the messages with the DSPMSGD command. To retrieve a 
message in RPG/400, you will have to write a little CL program that uses the RTVMSGD 
(Retrieve Message Description) command. You pass the message ID (and maybe message file 
name, unless you hard-code it) to the CL, have it execute the RTVMSGD, and return the 
message text. There are some options in DDS for using messages, both as constants and as error 
messages — see the MSGCON and MSGID sections in your DDS manual. I don't remember 
offhand the command, but I know that when I brought a message member from the S/36 to the 
AS/400, there was a command that converted the S/36 member to an AS/400 CL program that 
you can compile and run. This generated program does an ADDMSGD for each message, putting 
all of your messages into the msgf so that you don't have to rekey them. (Also see the 
CHGMSGD command.) 
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Selected from DataNetwork's electronic bulletin board 
From: J. M. of Casa Grande, AZ To: All 

I have heard about the migration/conversion from the S/36 to the AS/400, but what about the 
other way?? We are planning on bringing up an AS/400 in August, replacing a S/36, and I 
understand pretty much the migration procedures. We are going to run in S/36 Execution 
Environment, and my question is this: what if after migrating to the AS/400,1 have files, 
libraries, etc. that are on the AS/400 that need to be moved to one of the remote S/36's? How 
does it work, does it work, can it work?? What steps will need to be taken to pull it off? Thanks. 

From: A. T. of Spotswood, NJ To: J. M. of Casa Grande, AZ 

To migrate back is really the same as to migrating from S/36 to AS/400. Save your files/libraries 
using the Save S/36 command (SAVS36LIB and SAVS360BJ?) to diskette or tape. Any 
libraries will need recompilation on the S/36. 
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Selected from DataNetwork's electronic bulletin board 
From: R. S. of Encinitas, CA To: C. P. of San Mateo, CA 

Is there an equivalent to the S/36 SSFGR auto record advance screen field attribute on the 
AS/400? I am searching the DDS manual but having no luck. I want to field exit from a field and 
then automatically advance. 

From: C. P. of San Mateo, CA To: R. S. of Encinitas, CA 

You've probably found it by now, but the equivalent of Auto Record Advance is CHECK(ER) 
(stands for Check End-of-record). There are a bunch of other CHECK conditions, such as 
CHECK(LC) (allow lower case), CHECK(RZ) (right adjust zero fill), CHECK(RB) (right adjust 
blank fill). Now for a little history lesson ... on the S/38, these keywords used to be AUTO(RA) 
(record advance), AUTO(RAZ) (right adjust, zero fill), etc. Along about Release 6 or so on the 
S/38 (about 4 years ago), the manual started to say "the CHECK keyword is preferred because it 
is compatible with DDS on other systems." As far as I knew at the time, DDS was only on the 
S/38. So was IBM quietly pointing to some future direction? 
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Selected from DataNetwork's electronic bulletin board 
From: K. C. of Chestnut Hill, MA To: All 

I am working on a CL program with an externally defined file. It has been working all right so 
far, but someone told me I need to use command DCLF in the CL. Well, I tried it and it still ran 
all right. My question is: do I really need this statement in my CL? As I said, it ran fine without 
it. 

From: C. P. of San Mateo, CA To: K. C. of Chestnut Hill, MA 

As far as using DCLF in a CL program, you only need to use it if the CL program is explicitly 
using the file. That is, if your CL program calls an RPG program that uses external files, you 
don't need to use the DCLF to tell CL about the files. 

However, there may be times when you want to use a display file or a data base file in a CL 
program. When you want to do this, you need to "declare" the file to the CL program, so it will 
know what you want. It's pretty much the same as an RPG program: if the program doesn't use 
any files then you don't have DCLF (or F-specs). 
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by Openbbs Contributor 

Selected from DataNetwork's electronic bulletin board 
From: A. T. of Spotswood, NJ To: All 

We are currently developing a brand new "from scratch" manufacturing system on the AS/400, 
and have now reached the point where we are designing files with DDS. How are programmers 
in the AS/400 or S/38 world naming their fields? Most of our experience has been on the S/36, 
and we have become used to using names like this one: XX999. The 'XX' is a two digit alpha 
code describing the file, i.e. IT for item master, CS for customer file, etc. The 999 is a sequential 
number from 001 to 999, assigned as fields are added to the file. 

It is our experience that after working with these "codes," they are easily recognized and often 
memorized. It is also advantageous because delete codes are always field name XXO, and the 
most important key field is XX001. 

We feel that naming conventions such as CSTNBR for customer number become too 
meaningless as fields are added, i.e. STLSP for steel selling price, NSTLSP for new steel selling 
price, and STLRVP for steel revised date. In some cases you are limited to using only the first 
letter from each word to name your field. Please keep in mind that these programs are being 
written in RPG/400 and we are limited to six digits. Another advantage in using the XX999 
codes is to eliminate typo's. Most programmers feel more confident using the numeric keypad 
and will make less mistakes using it. CSTNBR is certainly harder. 

What I am really looking for is enough comments to justify using the codes that we are used to. I 
would appreciate hearing pros and cons. 

From: B. K. of Roslyn, NY To: A. T. of Spotswood, NJ 

I wouldn't code field names with numbers. I follow almost the same format, first two letters to 
describe the file name, but the last four are alpha. Naturally, when you use the same field name 
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time after time you will memorize it, but I believe it can be memorized much faster if it the field 
name is all alpha. At least they can take a good guess, or it may be obvious. In your format, 
someone who doesn't know the file will go nuts looking at the field name list all the time. 

One thing you haven't mentioned is how you defined arrays. I don't know how it's done on the 
AS/400 yet. But since we use ASNA's RPG III, we defined array field name as xxxnnn, where 
xxx= array name and nnn=e1ement number. We then define an external data structure and 
overlay it with an actual array. This way I have the best of both worlds. 

If anyone knows of a better way of handling this, I am looking forward to any suggestions that 
would make it easier to migrate to the native mode. 

From: E. M. of Torrance, CA To: A. T. of Spotswood, NJ 

I concur about naming fields. I use the same method (I also use ASNA's RPG-III product). To 
me, CUNAME, CUADDR, CUCITY, CUSTAT, CUZIPC, and CUFONE make a lot more sense 
than CU002, CU003, CU004, CU005, CU006, and CU007 for customer master file fields. 

Think about this: can you tell right off if field CU006 is numeric or alphameric? What if you saw 
(or entered) the following line: 

Z-ADD CU006 TEMP 

If I were typing field names (actually field "numbers") I wouldn't be able to tell if I've made a 
mistake. Since CU006 holds the customer's zip code, however, this C-spec is OK. What if 
CU006 had been the address? CRTRPGPGM (or RPGC) would have given you a terminal error. 

Also, I think that numbers can be mistyped very easily by transposing the digits. My roommate 
was balancing his checkbook the other night and he spent half an hour finding that he had written 
a check for (something like) $247 and written it on the checkbook as $274. Of course he was off, 
and the statement didn't jive. 

Alpha names can also be mistyped by transposing letters, but since letters make up words that 
are distinct, transpositions are harder to do and are more easily detected. For example, typing 
CUNAEM for the customer name field is obviously an error; CU002 could be typed as CU020 or 
even CU003 very easily and, since all numbers are "legal" it wouldn't be spotted unless you 
KNEW the application. 

The only benefit I can see with numbered field names is that it is extremely easy to make up the 
name for a brand-new field: you just add 001 to the highest number used so far. Making up an 
UNUSED 4-letter combination (never mind the @%*$!@-type words) is much harder. But it's 
worth the effort — I think. 

From: A. T. of Spotswood, NJ To: E. M. of Torrance, CA 

I hadn't thought of using two digit codes such as CU, and then a 3 digit ALPHA code. That 
makes sense because you could re-use the most frequent ones (i.e. like SP for sell price, ITM for 
item#), but you would still keep all fields from a file in order. I'll have to bounce this one off of 
my fellow workers, see if they can come up with any problems with this one. 
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Selected from DataNetwork's electronic bulletin board 
From: A. H. of Milwaukee, WI To: All 

Did anyone go to the OfficeVision announcement yesterday? Looks like you'll have to get into 
PC's in a serious manner ... OS/2 EE is a monster, but looks like it will be the way to go in the 
future. They did mention Release 2 of OS/400 for 4Q89. The mainframers outnumbered 
everyone in Milwaukee. At the first break I just packed up all the info I could get my hands on 
and split. This announcement at least had decent printed info, unlike the AS/400 announcement. 
Don't write-off your S/36 yet, it will be able to participate via 5250 comm in the OS/2 EE via 
APPC and LU 6.2. 

From: R. M. of Montgomery, AL To: A. H. of Milwaukee, WI 

Around here in Alabama the DP folks are going to have a hard time justifying spending the 
thousands of dollars for disk and memory upgrades on all of these "OS/2 will run on these" 
PS/2's. You know, the ones that IBM sold that were ready to run OS/2 ... minus adequate 
memory and slow as Christmas disk drives. If you thought users had trouble doing one thing at a 
time, now with OS/2 they can MULTITASK!!! Kinda sets you back a bit, eh? 
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From: K. C. of Chestnut Hill, MA To: All 

I am trying to put the workstation ID and the user ID onto my workstation entry screen. Can 
anyone tell me how to do this in AS/400 native mode? If possible, please tell me specifically and 
step by step so I won't have to keep sending messages back and fourth. I really appreciate any 
help from anyone, as I am baffled trying to figure it out from the books. Thank you very much. 

From: C. P. of San Mateo, CA To: K. C. of Chestnut Hill, MA 

You can try the following and see what you prefer. 

Within RPG, you can use the "file information data structure." This is a fancy DS that you can 
"associate" with a file, and it gives you all kinds of data about the file and operations done with 
it. DataNetwork had an article about this a few months back. In any event, the code looks 
something l ik e this (see Figure 1). 

The idea with this is that the "WSDS" data structure is identified as the INFDS for the 
workstation file (by means of the continuation F-spec). The first POST operation, without factor 
1, retrieves the WSNAME. The second POST operation, with factor 1, retrieves the device name 
and the user ID. If you can do an EXFMT or WRITE operation before you need the device/user 
ID, then you won't need the first POST operation (because the I/O to the workstation will cause 
the INFDS to be updated with the WSNAME). If you need the device/user ID prior to your first 
workstation I/O, then the POST/POST technique works. 

You can also use the CL RTVJOBA (Retrieve Job Attributes) command to get the workstation 
and user ID, then pass that to your RPG program (example in Figure 2). 

The "job" parameter in the RTVJOBA command is the name of the job using the command. For 
interactive jobs, that is the name of the terminal. You might want to use the CL technique if you 
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are submitting a batch program, and want to track who/where the job came from. 

From: K. C. of Chestnut Hill, MA To: C. P. of San Mateo, CA 

I looked up the RTVJOBA command in the CL book and didn't find any parameters or options I 
could use with it. So then I typed in GO VERBS, found it and pressed CMD 4 to browse the 
available options. As far as the WSID, here is what you suggested: 

RTVJOBA JOB(&WSID) USER(&USID) 

You said the "job" parameter is the name of the job. Do you mean that I should substitute the 
name of my program where the word "job" is (before the wsid), or did I misunderstand you? I 
have one more question concerning this. I am using an externally defined screen format, and 
need to know how I should go about coding it into this file (my DDS specs). Anything special I 
should be doing? 

From: C. P. of San Mateo, CA To: K. C. of Chestnut Hill, MA 

Let me see if we can use a little example here, maybe it will hit some of the questions. First, 
make up a mini-display file, like this (see Figure 3) 

Enter these A-specs into a source file, give the display file some name, say DSTEST. Use the 
CRTDSPF command to create the display file using the source. 

Now, enter this CL source (see Figure 4) into a CL source file, call this program something like 
CLTEST: 

The DCLF command tells the program to use the test display file. The RTVJOBA should get the 
workstn ID and the user ID. The SNDRCVF tells the program to show you the test display file. 

After you compile this program, with CRTCLPGM, if you run it online it should show you your 
workstation ID and your user ID. 
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From: K. C. of Chestnut Hill, MA To: All 

I am currently working on a workstation program. In this program the input from the operator 
will include an input field asking to enter a store number. If the store is not valid, I want to 
display a message that says "Invalid Store" at the bottom of the screen. The message will show in 
a field that I have defined on the screen on line 24 that is 30 positions long. I want to put out the 
message (as I did on the S/36) using a message member. Now my questions: 

1) I did create a message file using CRTMSGF, and added the message "Invalid Store" using 
ADDMSGD. Where is this file stored? How can I look at messages that I have added? 

2) I gather (from IBM) that I am to use SNDPGMMSG to send this message. As I look at the 
command in the book, it seems to imply that this is to be used to send a message to the users 
MSGQ, and not to the program, which is what I want to do. I want it to appear, as I said, at the 
bottom of the screen in the space I have provided. Is this really the command I am looking for? If 
so, what is the code needed? Could you please give me an example using my message? 

3) Q & A also said that I need to use the QCMDEXC to accomplish putting out the message. 

Could you please give me an example of how I would use this to put out my message? 

4) Is there anything else that I need to do to have my message appear (like a message member on 
the S/36) at the bottom of my screen in a defined field. Thank you very much for your help. 

From: C. P. of San Mateo, CA To: K. C. of Chestnut Hill, MA 

Using messages should be a bit simpler than that. 

1) The message file that you created is stored in whatever library you created it. It is a separate 
type of object, just as programs and data files are types of objects. If you do a DSPLIB of the 
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library, you will see it show up with object type *MSGF. 

You can get a printed listing of messages in any message file by using the DSPMSGD command: 

DSPMSGD RANGE (*ALL) 

MSGF(lib/msgfname) 

DETAIL(*BASIC) 

OUTPUT(*PRINT) 

where "lib" is the library name, and "msgfname" is the message file name. 

You can also use the DSPMSGD command to review messages at your terminal. 

2) To get a message into your program, you can write a short CL program. Your RPG program 
calls the CL, which retrieves the message and returns the message text to your program. At that 
point, the message text is in a character field, and you can use it like any other field. For 
example, in RPG, code this (see Figure 5). When you return to RPG, the text will be in PMTXT. 
The CL might look like this (see Figure 6). 

On the RTVMSG line, "lib/msgf" is the library and name of your message file. You can hard- 
code these into the program. If you want to make GETMSG a general purpose retriever, you 
could pass the library and message file name as parameters also. 

You might also be interested in reviewing the ERRMSGID DDS keyword. By using 
ERRMSGID, you can get OS/400 to take care of the details of retrieving and placing the 
message text on the display. 

From: L. P. of Pleasanton, CA To: K. C. of Chestnut Hill, MA 

IBM telling you to use SNDPGMMSG sounds like they expect you to use a message subfile for 
your message line. They are partially covered in the DDS manual but not well enough that I have 
tried them yet. To use the S/36 approach to messages, I think you have to use the method 
someone else described earlier (calling a CL program that will retrieve the text for you, then 
displaying that field on your message line). 
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by Craig Pelkie 

One of the first discoveries you'll make when learning the AS/400 is that you have to learn "CL." 
From sign on through sign off, everything you tell the AS/400 to do must be done with CL. CL is 
used in such diverse activities as system control, programming, testing, and configuration, yet it 
is sometimes difficult to grasp the concepts of CL programming. 

This series of articles will teach you many techniques for creating your programs. For greatest 
success, you should become familiar with two manuals: Control Language Programmer's Guide 
(SC21-8077) and Control Language Reference, Volume 1 (SC21-9775). 

Why CL Programs? 

Why are CL programs necessary, anyway? If we can call programs interactively, and have 
programs call other programs; if we can submit batch jobs with a command option; if we can use 
external files so that our programs "know" which files to use — then why are CL programs 
needed? 

In some cases, they aren't. For example, if you are developing programs, you can create the 
source, compile, and test without ever having to use a CL program. True, you will use CL 
commands, but then only one at a time. You can quickly correct any errors, and run the 
command again. When using CL, your system operators usually rely on the "one-command-at-a- 
time" method. 

However, there are many times when the job at hand will not fit the one-command-at-a-time 
approach. For instance, you might need to run a program using different files from the ones you 
used for compiling. You might need some system functions that are only available within CL. 
You might want to create long and involved batch jobs. For all of these examples, you must use 
CL. 

What's Wrong With CL? 
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What's wrong with CL is that nothing else quite resembles it. System/36 programmers use OCL; 
mainframe programmers use JCL. Those languages are really "subsets" of CL, in terms of 
functions supported. The only programmers that are apt to feel comfortable with AS/400 CL are 
System/38 programmers, because the versions are practically identical. 

Another problem with CL is that you really can't get away from it. For anything beyond the 
simplest of programs, you will need to write, test, and eventually modify CL programs. 

Expect some slides back down the learning curve. As you learn CL programming, the good news 
is that you will reach a point when everything will "click." In a short time, you will become 
proficient and imaginative. The following techniques and suggestions should shorten your time 
of uncertainty. 

If you want to write good CL programs, and really feel that you have a command of the language 
and the machine, you will need to start with the basics. You must leam the art of "reduction." 

Want to Learn CL? Practice Reduction. 

So let's take a look at some CL. Figure 1 is a program that I use to recompile all of the RPG 
programs in a library. I need this for a project I'm working on, because there are a lot of mass 
changes in it. It is simpler to recompile everything than to search for the specific programs I 
need. 

Compare Figure 2 with Figure 1. They are identical programs. Which do you prefer looking at? 
Why? What do you like and dislike about each of them? 

This comparison illustrates what I call the principle of "reduction." That is, we take a program 
and reduce it into elements that are easier to understand. For example, look at Figure 1 again. 
Don't read the lines of code, just look at it. It's a blob! Without reading each line, you would be 
hard pressed to pick out the loop, the condition controlling the loop, and the conditional 
processing. Closer examination doesn't help too much; it's difficult to be certain what the 
parameters of each command do. The "think time" for each statement is too long. 

So what? you say. It's only 14 lines, and you can figure it out in about a minute. The problem is, 
you may soon be called upon to write, debug, or modify CL programs several hundred lines 
long. Several hundred lines of this type of code are actually worse than old RPG programs that 
use lots of GOTOs. At least in RPG, the fixed format gives some structure to the program. 

And that is one of the greatest advantages of reduction. By creating an apparent structure to your 
CL programs, you can reduce the amount of thinking required to understand the program. Look 
at Figure 2 now. This version of the program, apparently, has two sections: the top part with the 
PGM and DCL statements, and the bottom part, where the action is. When you look at Figure 2, 
your eyes go first to lines 1-8, then to lines 16-18.1 have done this on purpose. By creating a 
"box" around the comments, I have drawn your attention to them, and helped your eyes "reduce" 
the program into two sections. From this, I extract a rule: 

Every program will start with a comment. You will use comments in all of your CL programs. 
The important thing is to describe what the program does and the parameters passed to the 
program, if any. Also, you will accent the comments with some sort of visual technique. 
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CL allows you to put comments wherever a blank is allowed, except in quoted character strings. 

I don't think that comments belong on the same line as a command. Make a command stand out 
as much as possible, so that you can read and understand it with minimum effort. In addition, CL 
programs tend to use commands in logical groupings. It makes more sense to comment on the 
group, rather than each command within the group. 

You can use other techniques to practice reduction, as shown in Figure 2, and as given below in 
order of their appearance: 

Use white space. You don't need to include "blank comments" in order to put space between 
logical groupings; just include a blank line. The white space in Figure 2 is designed to lead your 
eyes (eyes=brain) to the significant features of the program. Notice that white space is not 
included after every line. If it was, then the white space would have no significance, and would 
make you wonder if the printer was double spacing. Use white space to set off features of the 
program. Sometimes the feature will be a single statement, such as on lines 14 and 32. By 
themselves, those statements are significant parts of the program. 

Lines 11 and 12 demonstrate another reduction technique. These lines are "declare" lines, and are 
used to tell CL about the variables used in the program. RPG programmers have trouble with the 
DCL at first, since variable definition within RPG takes place anywhere in the RPG program. 

The CL rule, though, insists that all "declares" come right up front. 

There are two specific DCL techniques shown, and one general CL technique. The first DCL 
technique is to alphabetize the variables that you use. With only two variables, it's hard to get 
excited about this, but where are you going to draw the line? And if you use different types of 
variables (for example, *DEC in addition to *CHAR), you should either alphabetize the 
complete list, or create two alphabetized groups, one of *CHAR and the other *DEC DCLs. I 
create two separate groups. 

The second DCL technique is alignment. That is, line up the keywords from statement to 
statement. By doing so, you see the statements as a group and thus reduce eye strain. Contrast 
this with the equivalent lines 2 and 3 in Figure 1. The difference may not seem like a big deal, 
but when you create a CL program using several dozen variables, you will want to be able to go 
to the front of your listing and quickly locate a definition. Several dozen lines of code hke those 
shown in Figure 1 are not helpful. 

The general CL technique is this: use the parameter keywords, not positional parameters, for all 
statements in a CL program, all of the time. WITHOUT FAIL. Parameter keywords help you to 
understand the function of a command 

Don't Get Mad At Me 

At this point, you may be pretty steamed up about all of these "thou shalts" and "thou shalt nots." 
After all, where do I get off, making all of these pronouncements and rules? 

Well, I am not vying for "guru" status. I can only point out that in 10 years of using CL, I have 
seen these problems happen over and over and over again. If you are new to CL, you probably 
want me to skip over this fluff and get to something substantial. In my opinion, this is the 
"substance" of CL programming. CL programming is concerned with bringing about an orderly 
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flow of work on your AS/400. If your CL programs look like the example in Figure 1, then your 
chances of error and unintended results are greatly increased. Both versions of the program could 
have bad errors, but with which would you rather work? To which one would you want to add 
more routines? In my opinion, Figure 1 is just plain "mental sloth." 

Help From SEU 

How are you going to get away from Figure 1? It turns out that SEU will help you quite nicely. 

A CL source program is entered into a source member in a source file, which is contained in a 
library. If you are unsure about these, read up on them in the manuals. When you use SEU to 
create the new member, the source type you want to specify is "CLP". That tells SEU to use CL 
syntax checking and formatting when you enter the program statements. 

To enter comment lines (starting with /*, ending with */), you can use the "Insert" SEU 
command. Just type the letter "I" over the statement number and press enter. 

When you are ready to enter a CL statement, use the "Insert with Prompt" SEU command. The 
prompt type that you want is Type "IP**" over the statement number, and press enter. 

SEU gives you an entry line at the bottom of the screen. Type in the name of the CL command. 

If you know the keywords that you're going to use, you can just keep typing on this line. If you 
don't know any of the keywords, or if you get stuck after a certain point, press F4; this takes you 
to the command prompt. Fill in any parameters that you need. When you press ENTER, SEU 
puts the completed statement above, and formats it similarly to Figure 2. That is, the command is 
shifted toward the center, with the command name set off. Continuation lines are automatically 
formatted for you as needed, as was done on lines 28 and 29 in Figure 2. Continue this for every 
command that you use in the program. 

Don't object to the amount of work that it takes to prompt for the commands. This is probably the 
quickest way for you to leam about the commands. By continually seeing the command 
parameters, and the context in which they are used, you will assimilate the options that are 
available. You won't get this by reading the CL reference manuals from cover to cover; you have 
to see it in action in front of you, many, many times. While you're at it, when you prompt for a 
command, press F10 and review the additional parameters, if there are any. 

After you've entered your statements, you can return to the "full screen" editing mode. Review 
your DCL statements and use the INSERT key to get things lined up. Look through the source. 
Figure out where you should put some white space. Put in a comment for major parts of the 
program. 

Indenting (shown on lines 28 and 29) is another useful technique. The CRTRPGPGM command 
is part of a DO group, which is part of a conditional statement. SEU has a shortcut way of 
indenting, so you don't have to use the INSERT key. It's called "shift right." To use it, go to the 
first statement that you want to shift, and type "RR", followed by the number of spaces to shift. I 
shift groups three spaces at a time, so my command to SEU is "RR3". Then go to the last 
statement that you want to shift, and type the same "RR" command and press ENTER. If you 
have a group within a group, you can shift the inner group after the outer one. If you decide to 
move everything back, use the "LL" (shift left) command. 
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Final Reduction Notes 


There are just a few more little things that I want you to notice. 

First, always use the PGM and ENDPGM statements to begin and end your program. If you are 
passing parameters to the CL program, you have to use the PGM statement. Without parameters, 
the compiler considers it optional. Use it. Also, put a "label" on the PGM statement; use the 
name of the program for the label. The reason for the label is to keep the name of the program 
right in front of you. Before long, you will be working with multiple CL programs, with one 
calling another, calling another, and so on. You will be sitting there with many listings, going 
back and forth. Put the label there so you can find the one you want. True, SEU or compiled 
listings put it at the top of the listing, but it's stuck in there with a lot of other text. The PGM 
label stands out as the first thing you see when you look at the statements. 

Use the ENDPGM statement, always. The reason for using the PGM and ENDPGM is the same, 
in reverse: so that you know, for certain, that you are looking at all of the program. For example, 
back in Figure 1, is line 14 the last line? Or did I slip, and delete a line or two before I saved the 
source member? Make PGM and ENDPGM two small anchors of certainty for yourself. 

Second, always use the "alpha" relational operators, not the "special character." Consider this: in 
Figure 1, line 11 uses the "=" sign; Figure 2 uses the "*EQ" in line 27 to perform the same 
comparison. Look in the Control Language Reference, Volume 1, page VI-140 for the list of 
operators. Notice that there are two notes indicating how the symbols might be used. I just think 
it will be simpler for you, and the next person after you, if you use the predefined alpha values 
shown in the chart. 

Now you know how a CL program should look. If you follow the suggestions I have mentioned, 
your comprehension of CL will rapidly increase. 

Shifting Gears 

At this point, we shift from the rules of CL programming to questions about what should be in a 
CL program. How do you tell it to do what you want? 

When all is said and done, CL is just another programming language. Approach CL 
programming just as you do RPG or COBOL. You must have a clear idea about what you want 
the program to do. In the words of one of my first programming instructors, "first what, then 
how." 

To illustrate what I mean, let's review the thinking behind the program shown in Figure 2. My 
goal was to create a program to recompile all existing RPG programs in a library. Since this was 
meant to be a simple utility, I didn't want or need to include very many options. Just being able 
to specify the library and the name of the source file would be enough. 

Starting with that general goal, I had to think about how I could get a list of programs already in 
a library. If I am at a terminal, I can use the DSPLIB (Display Library) or WRKOBJ (Work with 
Objects) commands to see a list on the screen. That's a starting point, but still not where I want to 
be. I don't want to copy the list from the screen to paper, then type it back in. However, knowing 
that the system can give me the list I want, I imagine that I can get that list into a program 
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automatically. This illustrates a principle to remember when you create CL: if you can manually 
do something using various commands, you can probably use the same or similar commands in a 
CL program. 

Applying the principle, you can begin to see how the commands fit together. If you were going 
to manually recompile all programs in a library, you would first display or print the list of the 
programs, then use the CRTRPGPGM command to create each program on the list. So the 
outline is taking shape. Get the list, then create the program. 

It turns out that the system provides a command that I can use to get a list within my program. 
That command is the DSPOBJD (Display Object Description) command, shown on lines 20 and 
21. By specifying the OUTPUT option as *OUTFILE, the command puts the list of objects into a 
physical file. 

As an aside, I can't remember how I learned about this feature of the DSPOBJD command, since 
it was several years ago when I first used it. For you to learn about the features and options of 
CL commands, you will have to read the manuals, scrutinize the prompt screens, and continue to 
read articles like this. If you are coming from the S/36, you might be able to use the various 
cross-reference lists that show the AS/400 equivalents of S/36 procedures. 

One suggestion for shortening your time spent discovering CL options is as follows: the first 
time you use a CL command — any CL command, including those like "PGM" and "DCL" — go 
to the CL reference manual and read the section about that command. Chances are, your first 
program will take several hours to complete using this method. Soon you will find yourself 
remembering the options. Another valuable purpose of reading the complete description of the 
command is that it will take you out of "subset" mode. Programming languages are so complex 
that you invariably slip into using just a subset of the available features. By continually pushing 
yourself, you will greatly add to your knowledge. 

Now that I know I can get a list of programs, I can use that list in my program. There will 
probably be more than one program to recompile, which implies some sort of repetition. In this 
program, since the list is made up of records in a file, I want to read and process each record until 
end of file. So now my problem is how to read a file in CL, get information from it, and process 
it based upon that information. Another consideration is that I have to know how to handle the 
end-of-file condition. 

If you frame your program in English (or your native language) first, you can refine it until you 
get to the point where you can directly translate into CL. For example, the problem is "recompile 
all of the RPG programs in a library." Thinking about how that is done manually, and framing it 
in English, the problem becomes 

- get a list of all RPG programs in a library 

- for each program, recompile it 

Continuing, we have to break out the "get a list" part of the problem. This becomes 

- for the given library, create a file containing the list of programs in the library 
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- read a record from the file 


- if the record indicates that the program is an RPG program, recompile it 

- if the file is at end-of-file, we're done 

Now we can translate to CL. The "get-a-list" part is done with the DSPOBJD to an output file. 
DSPOBJD is one of a number of CL commands that allows output to a predefined file. Rather 
than simply sending output to the screen or printer, you can direct the output to a data-base file. 
These predefined files contain specific fields that you can use in your programs. You can use 
these files in any type of program, and create logical files over the predefined file if you want. 

The "read a record" part is on line 24, the RCVF (Receive File) command. In the absence of any 
file overrides, RCVF reads the file from record 1. Immediately after the RCVF command, you 
have to check for end-of-file. That is, if you try to read the file, and no record is there, what are 
you going to do next? Checking for end-of-file is shown on line 25, using the MONMSG 
command. I will cover that soon. 

Assuming that a record was read, you now have to determine if the record, which contains the 
name of a program in the library, is the name of an RPG program. In other words, when you use 
DSPOBJD to create the list of programs, you can't specify that you want the list to contain only 
RPG programs. The list contains all objects of type "*PGM". However, the "object attribute" is 
contained in the record. That attribute is tested on line 27. If the record contains the name of an 
RPG program, then... 

Then what? It turns out that CL has an IF/THEN/ELSE command, used exactly the same as in 
other languages. IF the condition is true, etc. The CL rule is that the THEN or ELSE condition 
can be one statement. Sometimes, you will want to do more than one thing in a THEN or ELSE 
condition. To accomplish that, you use a "DO group." A "DO group" is created by the DO and 
ENDDO commands (no jokes about DO-DO, please). You can include any number of statements 
between the DO and ENDDO. CL evaluates the "DO group" as the "one statement" required in 
the THEN or ELSE condition. 

You can include other conditional statements within the "DO group," with additional groups 
contained within it. However, the "nesting" can only be up to ten levels deep, so you might have 
to be careful in some cases. Using the rules described earlier, you can use indenting to set off the 
nesting level. In fact, you will want to do this. One annoyance of compiled CL listings is that the 
nesting level is not printed to the side of the listing, so you have to match up your DO and 
ENDDO statements manually. Using indentation helps you determine where the groups begin 
and end. 

After the IF condition, you have to decide what to do next. In this program, you want to continue 
processing the list, so you need a "loop." Much to its detriment, CL does not have an iterative 
DO statement, such as DO by count, DO UNTIL or DO WHILE. So you have to create loops 
with the old-style GOTO and TAG type statements. The GOTO on line 32 sends the program 
back to the RCVF statement. In this case, the "tag" is the statement label on the RCVF 
command. You can put a statement label on any command in a CL program. I suggest that you 
use statement labels only on statements that can be branched to (in addition to the PGM 
statement). 
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So, you've now been through some of the "thought process" that goes into creating a CL 
program. Longer programs are just continuations of the process. By laying out the framework of 
the program first, you can fill in the details of each section as you go along. You will soon 
recognize the common constructs. For example, the "read a file" construct is usually made up of 
lines 24, 25 and 32. 

Looking For the Exceptional 

CL is like any other language in terms of handling exceptional conditions. Some of the 
exceptions are relatively harmless, and even expected, as the example of reaching end-of-file 
shows. Other exceptions can be more serious, such as trying to CALL a program that doesn't 
exist. If you use a CL command that can potentially encounter exceptions, you have to decide if 
you are going to take care of the exception or if you are going to allow the system to take care of 
it. You will usually want to take care of the exceptions in your program, since the system uses 
the somewhat brusque method of announcing the error at your terminal (or the operator's, for a 
batch job) with cancel or dump options. 

There is an extensive list of exceptions that can happen from running a command. The complete 
list is shown in the Control Language Reference, Volume 1, Appendix E. How are you supposed 
to know what exception occurred? For example, the CPYF command lists 21(!) different 
exceptions that can occur, all of which are "fatal." 

The method used in CL is the MONMSG (Monitor Message) command. With MONMSG, you 
tell CL that you want to "monitor" for specific exceptions. Or, if you don't care about a specific 
error, but just want to monitor for an error, you can use a "generic" MONMSG. 

The MONMSG on line 22 tells CL that you want to check for any exceptions resulting from the 
DSPOBJD command. Using this form of the MONMSG, the messages that are monitored are 
those generated by the immediately preceding command. There are 15 exception messages that 
can be generated from the DSPOBJD command, none of which are good news. If any of those 
exceptions occur, then the DSPOBJD command has failed for the purpose of this program. You 
won't have the output file that you need for the rest of the program. Rather than monitor for the 
specific messages that DSPOBJD can encounter, you can specify the "generic" monitor for 
message "CPF0000". That is a catch-all. By monitoring for the catch-all (which implies that at 
least one of the unwanted messages was sent), you can tell CL to do something based upon the 
message. In this case, the "something" is to return from the program, shown by the EXEC option 
on the MONMSG command. The EXEC option is limited to "one statement," but like the THEN 
or ELSE option, you can use a "DO group" to use more than one command if necessary. 

The RCVF command is followed by a MONMSG of its own. The RCVF command can generate 
11 different messages, but the only one that would be encountered in this situation is the end-of- 
file message. Rather than be concerned with the specific message number for end-of-file 
(CPF0864), you can use the generic form to do what you want. In this case, at end-of-file, you 
end the program. 

You can do practically anything that you want in the MONMSG EXEC parameter. For example, 
you may be able to correct the condition causing the exception within your program. When you 
write CL programs, you should refer to the list of messages that can be monitored, and determine 
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if you are interested in monitoring any of the specific messages. If you are, use a MONMSG 
command for that specific message. If you don't care about any of the specific exceptions, you'll 
still have to accommodate the exception in some way, or the system will do it for you. If you 
don't want to do anything as the result of an exception, just use the MONMSG without the 
EXEC parameter. That tells CL that you know there's an exception, but you don't care, and you 
don't want the system to butt-in, either. 

There are other ways to use MONMSG. For instance, you can set up a "global" MONMSG so 
that you don't need to put MONMSG after each statement. This will be covered in later articles 
and examples. If you're interested in this topic now, read the MONMSG command description in 
Volume 4 of the Control Language Reference. 

Compiling the Sample Program 

Because the example program uses a data-base file, you need to create or verify the existence of 
the file before compiling the program. All files used in CL programs are "external" files, whether 
or not the files are defined with DDS. When you compile the CL program, the compiler retrieves 
the file definition. If the file is defined with DDS, the definition includes all of the fields, with 
their lengths and attributes. If the file is not defined with DDS, the compiler retrieves the 
definition as a single field, considered to be a character string whose length is equal to the record 
length of the file. 

In this program, the DCLF statement is looking for file QADSPOBJ in library QTEMP. Why 
QTEMP? If you think about it, this program could be long running, since it will be compiling a 
list of many RPG programs. So it will usually be submitted as a batch job. By using files in 
QTEMP for batch jobs, you tell the system that those are "scratch" files. When the batch job 
ends, its QTEMP library is "deleted," along with anything that was in it. So for all work files 
(and other objects) that are unique to a job, you can use QTEMP to hold them. That way, even if 
this program was running concurrently in the system with itself, the work files would not 
interfere with each other. 

However, the problem is still to compile the program: it expects the file to be in QTEMP when 
you compile it. You can create this file in your interactive QTEMP by running the DSPOBJD 
command shown on lines 20 and 21. That will create the file in your QTEMP. Then compile the 
program. You don't have to be concerned about the file disappearing from your QTEMP after 
you compile it. When you run the program, it won't need the file until it reaches the RCVF 
statement. By that time, the file has been created by the DSPOBJD command preceding the 
RCVF. 

A final "loose end" is shown on lines 27 and 28, where the variables &ODOBAT and 
&ODOBNM are used. Why are these being used, if they weren't in DCL statements? And how 
do you know which fields to use? 

When you use the DCLF command in CL, the compiler "declares" the fields used in the file. For 
DDS defined files, the variables declared are the field names preceded by the "&". So you don't 
have to use your own DCL statements for fields that are in a file. 

How do you know which fields to use? You can get a list of fields that are in any file with the 
DSPFFD (Display File Field Description) command. The list of IBM command-output files is in 
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Appendix D of the Control Language Reference, Volume 1. If you want to use the output file of 
a command, use DSPFFD on the file name shown in the appendix. The list tells you the names of 
the fields and provides a text description of what they mean. 

Sum Up and Up Next 

You can accelerate some of your learning by getting away from the programmer and operator 
menus. I prefer using the command entry display. If you are on a menu, you can get to it by 
entering CALL QCMD. This display lets you see all of the commands that you've entered, along 
with any messages, shown right beneath your entries. By typing the names of the commands, 
rather than mechanically selecting numbers from a menu, you will get into the swing of things 
more quickly. Scoff if you will, but you're retarding your progress by limiting yourself to only 
the programmer menu or PDM. 

This article has covered a lot of territory. If you establish good CL habits right from the 
beginning, you'll be able to dramatically shorten the time it takes you to learn CL. You learn best 
by seeing it and using it over and over again. If you always take shortcuts, you will be limiting 
your imagination. 

Next time, I'll go easy on the philosophy. There are a lot of interesting techniques to cover, some 
of which will be: passing parameters to, from, and between programs and using the character 
string functions of CL to handle string and array(!) processing. We'll also cover some additional 
compile and execution options for CL programs. We'll continue with articles about using files, 
and using CL to control your files for advanced uses. We'll also show you how to write "utility" 
programs, including useful commands. 


SIDEBAR 

The Ten Reduction Commandments 

1) Start every program with a comment, describing the program and its 
parameters. 

2) Use White space to set off features of a program. 

3) Declare all variables in the front of the program. 

4) Alphabetize the variables you declare. 

5) Use parameter keywords, not positional parameters, for all variables. 

6) Line up the keywords from statement to statement. 

7) Indent structured programming groups. 

8) Always use the PGM and ENDPGM statements to begin and end your program. 

9) Always us the "alpha" relational operators, not the "special character." 

10) Utilize the functions of SEU to help the reduction process. |TAG SEP| 

Figure 1 Bad style CL program 

01 PGM &SRCFILE &LIB 
02 DCL &SRCFILE *CHAR 10 
03 DCL &LIB *CHAR 10 
04 DCLF QTEMP/QADSPOBJ 

05 DSPOBJD &LIB/*ALL *PGM OUTPUT(*OUTFILE) + 

06 OUTFILE(QTEMP/QADSPOBJ) 

07 READ: RCVF 

08 MONMSG CPF0864 EXEC(DO) 

09 RETURN 

10 ENDDO 

11 IF &ODOBAT = 'RPG' THEN(DO) 

12 CRTRPGPGM &LIB/&ODOBNM &LIB/&SRCFILE 

13 ENDDO 

14 GOTO READ 

Figure 2 Improved style CL program 

P 

0i /********************************************************************/ 
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02 /* RECREATE ALL RPG PROGRAMS IN A LIBRARY 
03 /* 

I 

04 /* FARMS RECEIVED 

/ 

05 /* 

I 

06 /* SRCFILE - SOURCE FILE NAME 

/ 

07 /* LIB - SOURCE FILE LIBRARY / COMPILED PROGRAM LIBRARY */ 

Qg /********************************************************************/ 

09 


10 MAKPGM: 

PGM 

PARM(&SRCFILE 

&LIB) 


11 

DCL 

VAR(&LIB ) 

TYPE(*CHAR) 

LEN(10) 

12 

DCL 

VAR(&SRCFILE) 

TYPE(*CHAR) 

LEN(10) 

13 





14 

DCLF 

FILE(QTEMP/QADSPOBJ) 



15 

16 

17 

18 
19 


/********************************************************************/ 
/* GET PROGRAM NAMES, RUN CRTRPGPGM CMD FOR EACH PROGRAM */ 
/********************************************************************/ 


20 

DSPOBJD 

OBJ(&LIB/*ALL) OBJTYPE(*PGM)+ 

21 


OUTPUT(*OUTFILE) OUTFILE(QTEMP/QADSPOBJ) 

22 

MONMSG 

MSGID(CPF0000) EXEC(RETURN) 

23 



24 READ: 

RCVF 


25 

MONMSG 

MSGID(CPF0000) EXEC(RETURN) 

26 



27 

IF 

COND(&ODOBAT *EQ 'RPG') THEN(DO) 

28 

CRTRPGPGM PGM(&LIB/&ODOBNM) + 

29 


SRCFILE(&LIB/&SRCFILE) 

30 

ENDDO 


31 



32 

GOTO 

CMDLBL(READ) 


33 

34 
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SQL, or the Structured Query Language as it was originally known, seems to be rapidly growing 
into a de facto standard data definition and data manipulation language for relational database 
management systems (DBMS), both within and outside of IBM. In the IBM orbit, SQL has also 
been designated one of the important standards comprising Systems Application Architecture 
(SAA). 

Origins 

IBM developed SQL (originally spelled SEQUEL, and still pronounced that way) as part of the 
System R project that it sponsored at its San Jose facility starting in the early 1970s. System R 
was a research project set up to investigate issues involved in the implementation of relational 
data management concepts on real-world, general purpose computing hardware. 

At the time the System R project started up, this was definitely a leading-edge assignment. Dr. 
Codd's first paper defining the relational data model had been published only a year or so 
previously. The only relational database implementation efforts going on at the time were small 
academic projects not necessarily oriented toward producing robust, readily usable results. 

Big Boxes 

The hardware targeted by the System R effort was mainframe gear. The early 1970s were the 
pre-PC era of computing and there really was no midrange computing, in the current sense of the 
phrase, then going on. The System/3 line, which we now tend to view, retrospectively, as a 
pioneering midrange system, was actually a small machine during an era in which there were 
only big machines or small machines. The System/3 had neither the architectural "elbow room" 
nor the raw size to support a relational DBMS. The mainframes of the day had both, however, 
and the System R project did a lot of groundbreaking work. 

What is SQL? 
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Among the problems tackled by the System R group, one of the more important was defining a 
straightforward way of precisely specifying the queries that users would want to make against a 
relational database. 

If the same question were freshly posed today, the answer might well take the shape of some 
object-oriented facility with an icon- or mouse/graphics-based user interface. But, at the time of 
the System R project's deliberations, on-line graphics were not a very standard item in 
mainframe environments (as, indeed, they still are not). 

The usual approach of the time was to define a linearly parseable formal language of some kind 
to address the problem area. This was the solution adopted by the System R group. The language 
designed was SQL. 

A Language 

SQL, then, is more similar than different from familiar high-level programming languages such 
as RPG and COBOL. Like these others, SQL has a formal syntax and features a repertoire of 
different statement types. Also like general purpose programming languages, SQL can be 
implemented in either compiled or interpretively executed versions. 

Evolution 

Like all of System R, SQL was written up in the academic computing literature in several of the 
many papers that the project produced. SQL evolved from early versions intended solely for the 
purpose of composing relational queries. It eventually combined additional statement types to 
perform data definition functions and still other statement types to perform data manipulations 
involving modification, not just retrieval. 

Definition 

In deciding to make SQL a complete DBMS language, enough new statement types to define a 
database from scratch had to be added. These are: 

COMMENT ON — Provides a way to enter up to 254 characters of comment text into the data 
dictionary record that defines a file in a SQL database. 

CREATE DATABASE — Creates all the AS/400 objects that, in combination, constitute a SQL 
database: a library, a journal, a journal receiver, a catalog and a data dictionary. 

CREATE INDEX — Creates an index from up to 120 fields for a given file in a SQL database. 
The index is an AS/400 keyed logical file. 

CREATE TABLE — Creates a file in a SQL database. These are the underlying real files — 
AS/400 physical files. 

CREATE VIEW — Creates a pseudo-file consisting of data elements from selected records 
and/or fields of one or more real files combined through specified relational algebraic operations. 
Users can query view files just like real files, but view files cannot, for the most part, be 
modified. 
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DROP — Gets rid of any desired file, view, index or entire database. 

GRANT — Allows file creators to selectively grant others the right to create new indexes for, or 
to perform queries or updates on, the file. 

LABEL ON — Provides a way to enter up to 30 characters of descriptive comments about each 
file or view, or up to 20 characters about each field, into the data dictionary records. 

REVOKE — Allows file creators to cancel any file modification permissions originally granted 
with the GRANT statement. 

Back to School 

Figure 1 contains the SQL source code that defines a database with several files having to do 
with some kind of college or university. First, a SQL database called SCHOOL is created. Then 
six files (SQL tables) and their primary key indexes are created to populate it. As their names 
indicate, these six files keep track of students, academic departments, classes, class sections, 
faculty, and enrollments. 

Files 

The syntax of these SQL statements is not very hard to follow. When creating a table, you first 
name the table, then provide a parenthesized list of fields that make up the file's records. Each 
field entry has the field name, the field type and length, and a declaration of NOT NULL if the 
field must always have some kind of value in it. 

Default Nulls, Null Defaults 

The AS/400's DBMS does not provide for null values distinct from zero or blank. On machines 
that do, a declaration of NOT NULL WITH DEFAULT means that, for each record of this file, a 
default value will be slugged into the field if you do not provide a value for it yourself. 

On the AS/400, the SQL defaults are blank for alpha fields and zero for numeric fields. This 
makes NOT NULL WITH DEFAULT superfluous because the AS/400 will set any missing 
alpha fields to blank and numeric fields to zero anyway. 

Other SQL dialects in the IBM machine family, though — notably DB2 on mainframes — do 
support nulls and also allow you to set any default value you want for a field. It might be a good 
idea to code NOT NULL WITH DEFAULT where it would be useful if the AS/400 fully 
supported the feature. Who knows? In a year or two or three the AS/400 might start supporting 
nulls and defaults, or your SQL/400 code might be part of an SAA application ported to a 
mainframe. 

Doing Data 

The heart of SQL are the statement types that can retrieve data or modify the database. The data 
manipulation statement types in SQL are as follows: 

COMMIT — Causes all database modifications specified since the last COMMIT or 
ROLLBACK to be posted to the database files. All locks held on these records are released. 
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DELETE — Allows you to specify one or more records to delete from a database file with 
Boolean selection logic based on record contents. 

INSERT — Allows you to add one or more records to a database file by defining what amounts to 
a query in which the answer file gets added, one-record at a time, to the database file named in 
the INSERT statement. The query-like logic used to create the new record contents can draw on 
any other field of a file in the database to which you have access. 

LOCK TABLE — Lets you acquire either a shared or exclusive lock on an entire database file. 

ROLLBACK — Causes every one of your changes to the database made since the last COMMIT 
or ROLLBACK to be abandoned. 

SELECT — Allows you to specify complex queries using implicit relational algebraic operations 
and explicit Boolean comparison operations. 

UPDATE — Allows you to selectively modify and/or replace the contents of particular fields in 
particular records of particular files in a SQL database. Once again, query-like logic can be used 
to define the records you want to change. 

Questions 

The SELECT statement is the heart of SQL because, in its earliest days of development as part of 
the System R project, the SELECT statement was essentially all there was of SQL. Lormulating 
queries was what SQL started out to do. 

Ligure 2 contains one of the enormous number of possible queries that could be run against the 
files of the database created by the SQL statements in Ligure 1. This query is a simple sounding 
one to state; it merely produces a list of the courses taken by a given student during Spring 
semester of this year. Even so, it has its subtleties. 

Courseload 

We start out by listing what we want to see in the way of answer file records. In this case we will 
be content with the code for the academic department offering each course, the course number 
and the descriptive title of the course. As you may have guessed, we had to put the name of the 
file we want them drawn from in front of two of the three field names on the first line of the 
query, because two of the three files we name in the LROM clause on the very next line have 
fields with the same names. 

The LROM clause can be used to assign shorthand names to the files being queried as well as 
just naming them. Doing so sometimes makes for less typing of long file names in long queries. 

It can also make things a bit harder to follow. We don't, as a rule, recommend doing this 
renaming trick. 

Where to Join Up 

If all we know are the first and last names of the student, then we have to select that student's 
record from the STUDENT file, join this record to the ENROLLMENT file, select only the part 
of this join that is for class sections meeting in the third semester of the 1989 school year, then 
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join this result to the CLASS file on equal values of department code and class number — the 
unique compound identifier for classes — and print these values, plus the class title, for each 
remaining triply-joined answer file record. 

As you can see, the WHERE clause in SQL SELECT statements does the lion's share of the 
work. Of the three main relational algebraic operations, project, select and join, project is 
implicitly specified by listing the fields you want displayed following the SELECT verb. The 
comparisons specified in the WHERE clause do the rest. When fields from the same domain, but 
different files, are compared for equality, an implicit join is being specified. The other 
comparisons are there to do whatever relational selecting is required. 

Don't Be Duped Unless You Want To Be 

Incidentally, we could have said SELECT DISTINCT instead of just SELECT on the first line of 
the query. Doing so tells SQL to squeeze out any duplicate records that it winds up finding in the 
answer file just before it is displayed for you. The nature of the files we are joining together for 
this query is such that no duplicates should be generated. Not asking for duplicate suppression 
when you don't expect to see any is actually a good SQL debugging practice. If duplicate records 
show up where they were not expected, either your files are corrupt or your query is improperly 
formulated. 

Order, Order 

The last line of the query is, yep, a sort specification for the answer file produced by this query. 
ORDER BY clauses can, as you might well imagine, get considerably more complex than this 
example. 

Just a Taste 

One query does not a language tutorial make. There are a good many features of the SQL 
language that would be hard to explore even cursorily without laying out enough sample query 
text to bust the staples on this issue. This is not the last SQL piece to come, however, and next 
month, when we have a look at how you can go about using SQL from inside your RPG, 

COBOL or PL/I programs, we can address more SQL features. There are plenty. 

Going Public 

Before we run out of room entirely, though, you should know a few more things about SQL's 
birth and upbringing. 

Having freely published the evolving SQL syntax and other language details during the years of 
the System R project, IBM never made any particular effort to keep SQL proprietary. The whole 
question of whether the company would ever offer a commercial product based on its relational 
DBMS research, in fact, was a lively item of speculation for quite a long time. 

The fruits of System R were eventually made available as relational DBMS software products 
which included SQL implementations as part of their basic design. Lirst, there was SQL/DS for 
users of the VM and DOS/VSE operating systems, then DB2 for the very large and complex 
MVS operating system environment. 
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Other Players 


The rather leisurely schedule on which IBM elected to go commercial with relational DBMS 
products incorporating SQL allowed others to get there first. Oracle Corp., in particular, built a 
SQL-compliant DBMS for DEC VAX machines. They have subsequently ported their product to 
a wide variety of additional computers and operating systems including, ironically enough, IBM 
mainframes. Over the past ten years, many other vendors have implemented relational DBMSs 
and versions of SQL to go with them. 

Linguistic Drift 

As you might imagine, the "dialect" problem has begun to rear its head. Not all SQLs are created 
equal, so to speak. The versions of SQL implemented under SQL/DS and DB2, for example, are 
not precisely congruent. There are significantly greater departures represented in AS/400 SQL — 
notably the non-support of null tokens. This can't help but complicate the creation of truly 
portable SAA applications. And to top things off, none of IBM's SQL dialects, of course, is 
exactly matched by other vendors' commercial products. 

Finally, there is an on-going American National Standards Institute committee process that aims 
to define a workable SQL standard. The preliminary SQL standard of the ANSI X3H2 
Committee will probably be implemented — more or less — by most vendors over the next few 
years, but a certain amount of Babel is probably inevitable in the short run. 

Alone and in Company 

Being compilable or interpretable, you might well wonder just how SQL fits into systems written 
in more general programming languages such as RPG and COBOL. Although an out and out 
compiler could be written to process all-SQL source programs, the usefulness of doing so is 
somewhat problematical. What SQL is designed to do is allow definition, query and modification 
of relational databases. SQL does not have facilities for fancy formatting of screens or reports or 
many of the other things you expect in a language suitable for general purpose systems 
development. 

As an interactive query and file manipulation tool, SQL can shine all by itself. The interactive 
SQL facility available as part of the AS/400 implementation of the language is what we have 
been concerning ourselves with in this month's installment. When the job at hand is development 
of entire MIS systems, though, SQL needs to split the labor with some language that can handle 
the parts of the job that have nothing to do with database access. 

Rider 

The approach that has been taken is to define standard ways in which SQL code can be 
embedded in programs that are written in a conventional programming language. The AS/400 
version of SQL includes support for embedding it in RPG, COBOL and PL/I programs. 

The basic SQL statement types define a relational database or manipulate it in terms of relational 
algebraic operations. A few additional statement types have been added to formalize the interface 
between the multi-record answer files produced by relational operations and the RPG, COBOL 
or PL/I code that expects to deal with just one record at a time. Next month, we'll take a look at 
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how it works. 


Figure 1 SQL database definition example 

SQL Database Definition Example 

CREATE DATABASE SCHOOL 
CREATE TABLE STUDENT 

(STUDENT# DECIMAL(9,0) NOT NULL, LASTNAME CHAR(15) NOT NULL, 
FIRSTNAME CHAR(15) NOT NULL, 

MAJOR CHAR(3) NOT NULL WITH DEFAULT, 

CLASSTAND DECIMAL(1,0) NOT NULL) 

CREATE UNIQUE INDEX STUDENT ON STUDEN (STUDENT#) 

CREATE TABLE DEPARTMENT 

(DEPTCODE CHAR(3) NOT NULL, NAME CHAR(25) NOT NULL) 

CREATE UNIQUE INDEX DEPT ON DEPARTMENT (DEPTCODE) 

CREATE TABLE CLASS 

(DEPTCODE CHAR(3) NOT NULL, CLASSNUM DECIMAL(3,0) NOT NULL, 
TITLE CHAR(30), CREDITS DECIMAL(2,1)) 

CREATE UNIQUE INDEX CLASS ON CLASS (DEPTCODE, CLASSNUM) 

CREATE TABLE SECTION 

(DEPTCODE CHAR(3) NOT NULL, CLASSNUM DECIMAL(3,0) NOT NULL, 
YEAR DECIMAL(4,0) NOT NULL, SEMESTER DECIMAL(1,0) NOT NULL, 
SECTION DECIMAL(2,0) NOT NULL, BLDG CHAR(3), 

ROOM# DECIMAL(3, 0) , FACULTY DECIMAL(6,0)) 

CREATE UNIQUE INDEX SECTION ON SECTION (DEPTCODE, CLASSNUM, 
YEAR, SEMESTER, SECTION) 

CREATE TABLE FACULTY 

(EMP# DECIMAL(6,0) NOT NULL, LASTNAME CHAR(15), 

FIRSTNAME CHAR(15)) 

CREATE UNIQUE INDEX FACULTY ON FACULTY (EMP#) 

CREATE TABLE ENROLLMENT 

(STUDENT# DECIMAL(9,0), DEPTCODE CHAR(3) NOT NULL, 

CLASSNUM DECIMAL(3,0) NOT NULL, YEAR DECIMAL(4,0) NOT NULL, 
SEMESTER DECIMAL(1,0) NOT NULL, SECTION DECIMAL(2,0) NOT NULL, 
GRADE DECIMAL(2,1)) 

CREATE UNIQUE INDEX ENROLLMENT ON ENROLLMENT 
(STUDENT#, DEPTCODE, CLASSNUM, YEAR, SEMESTER, SECTION) 

Figure 2 SQL query example Figure 2 

SQL Query Example 

SELECT CLASS.DEPTCODE, CLASS.CLASSNUM, TITLE 
FROM STUDENT, ENROLLMENT, CLASS 

WHERE FIRSTNAME = 'JOHN' AND LASTNAME = 'SMITH' 

AND STUDENT.STUDENT# = ENROLLMENT.STUDENT# 

AND YEAR = 1989 AND SEMESTER = 3 
AND ENROLLMENT.DEPTCODE = CLASS.DEPTCODE 
AND ENROLLMENT.CLASSNUM = CLASS.CLASSNUM 
ORDER BY CLASS.DEPTCODE, CLASS.CLASSNUM 
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Clever Use of PC Support Will Allow Remote Job Entry From the PC 

Normally, when you refer to Remote Job Entry (RJE) on the System/36, you think of MSRJE. 
Perhaps you have a local job designed to initiate MSRJE to receive a data file from a host 
computer in order to process the data on your local machine. Did you know that you can perform 
a similar task using a PC as the "local" system and the System/36 as the "remote host," or visa 
versa, just by utilizing PC Support? This is known as DOSRJE. 

Those of you using PC Support probably know how to transfer files back and forth from PC to 
System/36. However, once you have transferred the data to the System/36, you must begin a 
separate job to process the data. It is this step of processing the transferred data which may be 
automated on the PC with DOSRJE. 

A Little Background 

Let's briefly examine how PC Support works. 

The session begins by establishing the communications link between the PC and the System/36. 
You start the 5250 router with the System/36 by issuing the PC command STARTRTR. 

STARTRTR processes a configuration file containing run-time environment parameters for the 
session. You may specify an alternate configuration with user-defined parameters when initiating 
the PC router, with the default configuration file being CONFIG.S36. 

If not already signed-on, PC Support will force sign on before beginning the System/36 router 
IWROUTER. Once initiated, the PC to System/36 link is complete. 

At this point in the session, you can make use of the various facilities that PC Support provides. 

The available software allows you to do file transfers, and to use System/36 print and disk 
devices as if they were PC devices. (See the PC Support Manual and the four-part, PC Support 
Series published in DataNetwork, April 1989 - July 1989 for more details on the available 
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facilities.) 


You end the session by terminating the router links with STOPRTR. The System/36 
automatically signs off if forced sign-on was performed, and DOS returns to normal use. 

Using DOSRJE 

The DOSRJE method also begins with STARTRTR and ends with STOPRTR. The difference is 
that you supply an alternate configuration file — not CONFIG.S36. To use an alternate file, you 
must explicitly tell STARTRTR by passing the name of the file as parameter 1. For example: 

STARTRTR MYCONF.JOB 

tells STARTRTR that we want to use MYCONF.JOB as the configuration file for the current 
session. It is the use of the alternate configuration file which is the basis for DOSRJE. 

There are many parameters which may be specified within a PC support configuration file. Our 
focus is on the OFFP parameter. OFFP defines the System/36 procedure that will be executed 
when STOPRTR terminates the routers. If OFFP is not present, the normal sign-off procedure 
OFF is executed if PC Support forced sign-on. 

OFFP may contain up to 256 characters, including an ENTER key stroke appended by the router. 
When STOPRTR is issued, the commands are processed as if you keyed them on the System/36 
command line. Any number of OFFP parameters may be included in the configuration and, yes, 
OCF statements are acceptable. 

For consistency, I have elected to name my alternate configurations the same as the System/36 
procedures I want to execute. Figure 1 shows the DOS configuration file named MYJOB.JOB, 
which specifies that I wish to execute the System/36 procedure MYJOB when STOPRTR is 
processed. 

Figure 2 shows a generic batch program which will process any configuration file specified as 
parameter one. The result of running this will be the execution of the System/36 statements in the 
configuration file specified in parameter one. 

Figure 3 shows a simple example of a batch job that uses PC Support to recall and perform the 
previously defined file transfer job, MYFIFE.TFR. Once the file is successfully transferred to the 
System/36, DOSRJE will execute the OCF statements specified in the configuration file, 
MYJOB.JOB. The System/36 OCF processes the System/36 file MYFIFE. 

Special Considerations 

If a configuration not containing the OFFP parameter previously initiated STARTRTR, you must 
issue STOPRTR before beginning DOSRJE. You may then start a second session by specifying 
OFFP in the configuration. The reason for this is that STARTRTR will only process 
EMUFATION and TOKEN RING parameters if it is restarted prior to issuing STOPRTR. 

In my experiments with DOSRJE, the System/36 procedure took on the status of EVOKED- 
YES, even if not explicitly evoked using OFFP. Therefore, the EVOKED OCF statement was 
always true. 
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Emulation HOT KEY keystrokes should be kept to a minimum to prevent interruption of PC 
Support unnecessarily. 

Figure 1 DOS configuration file MYJOB JOB 

Figure 1 

DOS Configuration File MYJOB.JOB 

SUPPORT/36 
RTYP 5250 

OFFP // EVOKE MYJOB 

Figure 2 Generic batch job to process any configuration 111 

Generic Batch Job Which Processes Any Configuration File 

0ECHO OFF 
rem DOSRJE.BAT 

rem PARM 1 = Name of S/36 procedure == DOS file %l.JOB 
STARTRTR %l.JOB 
IF ERRORLEVEL 20 GOTO EXITRJE 
STOPRTR /F 

IF ERRORLEVEL 20 GOTO EXITRJE 
CLS 

ECHO System/36 job has been submitted. 

PAUSE 
:EXITRJE 

Figure 3 Example of batch job 

Example of Batch Job 

0ECHO OFF 

CLS 

rem 

rem Transfer a file and begin processing on System/36 
rem 

IF NOT EXIST MYFILE.DAT GOTO ERR1 
rem 

STOPRTR /F 
STARTRTR CONFIG.S36 
STF.COM 

rem recall transfer of MYFILE.DATA to System/36 

RFROMPCB MYFILE.TFR 

IF ERRORLEVEL 20 GOTO ERR2 

PAUSE 

STOPRTR /F 

CLS 

rem submit System/36 job 

CALL DOSRJE MYJOB 

rem 

GOTO DONE 
: ERR1 
CLS 

ECHO PC file MYFILE.DAT not foune ... request canceled. 

PAUSE 
GOTO DONE 
: ERR2 
CLS 

ECHO File transfer error ... abnormally terminated. 

PAUSE 
GOTO DONE 
: DONE 

STOPRTR /F 
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Utility Converts AS/400 System/36-compatible F & I Specs to DDS 

Stepping out of the AS/400's System/36 Execution Environment is not exactly a piece a cake. 
You should use every tool you can find that will expedite the transition. An especially useful tool 
is the one given to you in this article. FI2DDS will create a DDS file description member from 
any F & I specification. This is something you could do manually, but why take all that extra 
time and add the possibility of error? 

Run FI2DDS as you would any other command. Just key it and press F4 to display the parameter 
screen. The command will prompt you for the member containing the F & I specs (assumes the 
member is in QS36SRC file), the library in which it resides, and the file name within the F & I 
member name (becomes the DDS member name). FI2DDS will create the DDS member in the 
QDDSSRC file of the library named in parameter 2. 

If the F & I member has multiple record types, the program will write another DDS R record, but 
it will be with the same name as the first record format. If you are creating a physical file, these 
formats will have to be broken out into logical views against the physical file, or made into 
separate physical files. 

The new DDS member will contain one field description line for each field referenced in the F & 
I member. If the file is to be indexed you will need to add the KEYFFDs. You may also need to 
do some editing if your F & I specs contain errors. For example, a zoned numeric, packed or 
binary field defined without decimal positions will need decimal positions added in the created 
DDS member. 

To get FI2DDS into your system, key RPG program FI2DDSR1 into source physical file 
QRPGSRC, CF program FI2DDS CF program into source physical file QCFSRC and command 
FI2DDS into source physical file QCMDSRC of a library. Then compile each member with 
option 14 of PDM placing the objects into the same library in which the source members reside. 
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Figure 1 FI2DDS command 

CMD PROMPT('Convert F&I Specs to DDS') 

PARM KWD(SRCPGM) TYPE(*CHAR) LEN(IO) + 

PROMPT('Member Containing F&I Specs’) MIN(l) 
PARM KWD(LIBR) TYPE(*CHAR) LEN(IO) + 

PROMPT('Library') MIN(l) 

PARM KWD(DDSMEM) TYPE(*CHAR) LEN(IO) + 

PROMPT('File Name in F&I Member') MIN(l) 

Figure 2 FI2DDS CL program 

FI2DDS: + 

PGM PARM(&SRCPGM &LIBR &DDSMEM) 

DCL VAR(&SRCPGM) TYPE(*CHAR) LEN(IO) 

DCL VAR(&LIBR) TYPE(*CHAR) LEN(IO) 

DCL VAR(&DDSMEM) TYPE(*CHAR) LEN(IO) 

ADDPFM FILE(&LIBR/QDDSSRC) MBR(&DDSMEM) TEXT('DDS created from + 
S/36 F&I specs') 

MONMSG MSGID(CPF7306) EXEC(CLRPFM FILE(&LIBR/QDDSSRC) MBR(&DDSMEM)) 
OVRDBF FILE(SRCIN) TOFILE(&LIBR/QS36SRC) MBR(&SRCPGM) + 

POSITION(*START) 

OVRDBF FILE(SRCOUT) TOFILE(&LIBR/QDDSSRC) MBR(&DDSMEM) 

CALL PGM(FI2DDSR1) PARM(&DDSMEM) 

ENDPGM 


Figure 3 FI2DDSR1 RPG program 
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In the AS/400 System/36 environment, #GSORT often slows down all other interactive users 
drastically. One of the reasons for this is that #GSORT is run at an interactive run priority of 20. 
Batch jobs (like #GSORT) should be submitted to batch, where they are run more efficiently 
without bogging done the interactive environment. 

But when you must run #GSORT in an interactive job, you can improve the interactive 
environment's performance by lowering the priority of the #GSORT jobs. You should use a 
number of 80 or higher (99 max), depending on the size of the input file. The higher the number, 
the lower the priority. 

We are doing our conversion to native "little-by-little," and I did not have the time to rewrite all 
the #GSORT procedures and programs. What I did do was use the SCANPROC program from 
the RESOURCELIBRARY (DataNetwork, June 1988) to find all of the #GSORT procedures. I 
added the following line to the beginning of each procedure: 

CHGJOB RUNPTY(80) 

This will let the #GSORT job run with almost no noticeable slowdown, and will allow the other 
interactive jobs to run at normal speed. (Please note that any user running these procedures has to 
have *JOBCTL authority in their user profile to run CHGJOB.) 

Art Tostaine, Jr. Spotswood, New Jersey 
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It is common knowledge that on the AS/400 you can call programs from programs, but did you 
know that you can also call a single command (IBM or user defined)? It's easily accomplished by 
calling the QCMDEXC program. Simply CALL QCMDEXC followed by two PARM statements 
from any HLL program. The first PARM statement passes the COMMAND and associated 
parameters, the second PARM statement passes the overall length of the COMMAND and its 
parameters. 

Here is an example of using QCMDEXC in RPG: If a certain error condition occurs in an RPG 
program, you want to start debug to examine the contents of a field. You would start debug 
(STRDBG) by CALLing QCMDEXC at the point an error occurred. 

ERROR IFEQ 'Y' 

CALL 'QCMDEXC' 

PARM QTXT 30 

PARM QLENGTH 155 

END 

Field QTXT contains the literal "STRDBG PGM(TEST) UPDPROD(*YES)". Field QLENGTH 
contains the number 30 which represents the length of PARM 1. The first PARM must be made 
up entirely of literals — no program variables are allowed. You must always define the second 
PARM as 15 with 5 decimal positions. 

You could then CALL QCMDEXC again to execute an ADDBKP command, and once again to 
end debug. 

Before you decide to call a command with QCMDEXC, be sure its use is not restricted to CL 
programs only. You can determine this by looking up the command in the CL Reference manual. 

You can also use CMCDEXC in the same way in a CL program. But why would you want to do 
this, since you can call commands directly? There may be times when you need to build the 
command/parameter string within the program and cannot hard code it. The format for a CL 
program is: 


Next 


Home 


Previous 










CALL PGM(QMCDEXC) PARM(command cmd-length) 
DataNetwork staff 
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by Art Tostaine 

Here are a few ideas on customizing the AS/400 Programming Development Manager. When I 
work on the AS/400,1 work in the native mode to take advantage of the increased speed. 

However, most of the programs I work with are System/36 compatible. These commands help 
the programmer "in and out" of the System/36 environment: 

Command MP: Modify System/36 procedure with same name as program 

STRSEU SRCFILE(&L/QS36PRC) SRCMBR(&N) TYPE(OCL36) 

This command is useful when using the Work with Members screen. It allows you to modify the 
Procedure in QS36PRC, without having to change the file name. It will use the same name as the 
program in QS36SRC. 

Command R6: Run System/36 procedure in S/36 mode 
STRS36PRC CURLIB(*SAME) PRC(&N) 

This command will start the S/36 session, run the procedure (and other nested procedures), and 
return to the work with members screen when it is complete. 

Command S6: Start S/36 session 

STRS36 

This command is similar to R6, except that it will not run any procedure. It is useful when you 
wish to run a catalog, or run a DFU update program. 

Command SD: Start S/36 SDA 

STRS36PRC CURLIB(*SAME) PRC(SDA) PARM(&N) 

This command will start the S/36 session and call SDA, passing the member name to SDA. This 
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command is useful after a successful compile is generated of a $SFGR member, and you wish to 
either view the screen formats or generate RPGII Input/Output Specs. 

Command CS: Create S/36 RPG Program without XREF listing 

SBMJOB CMD(CRTS36RPG PGM(&L/&N) SRCFILE(&L/QS36SRC) SRCMBR(&N) 
OPTION(*NOXREF) 

On the System/36, the cross reference listing option defaults to NOXREF. On the AS/400, it 
defaults to *YES. Printing the cross reference when not needed is a waste of paper and computer 
time. This command will compile your RPG/II program without the cross reference. 

You can add these commands as user-defined options to the Work with Members screen of 
PDM. To do so press function key 16, and then function key 6 to add. Put the two-character 
option code to call the command in the first field, and the command in the second field. 

Art Tostaine, Jr. Spotswood, New Jersey 
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by Midrange Computing Staff 

If you find yourself in a situation where you would like to call a program from within a CL 
program, but do not want to return to the calling program, you can use the TFRCTL command 
instead of CALL. It passes control to the called program and removes the transferring program 
from the return stack. When the called program ends, control will return to the last program that 
was CALLed prior to the program that issued TFRCTL. 

There is one major restriction: you can only pass parameters that have been passed to the calling 
program. The CL program must pass the parameters to the program through CL variables. 
Values cannot be passed as constants, null parameters, list of values, or CL variables not defined 
on the PGM command. 

A maximum of 40 parameters can be passed to the called program. 

DataNetwork staff 
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by Midrange Computing Staff 

Even though the Allocate Object (ALCOB J) command is normally used in a routing step to 
reserve an object for later use, it can also be used to determine if an object is in use. This could 
be helpful in any job that requires an exclusive use of an object. 

Running ALCOBJ with a lock-state parameter value of *EXCL (Exclusive, no read) against the 
object in question and subsequently monitoring message (MONMSG) CPF1002, you can 
determine if the object is busy. In the example CL program in Figure 1, a program message is 
issued if an object-name/object-type of a specified library is in use. 

DataNetwork staff 

Figure 1 Example of ALCOBJ command 

PGM PARM(&0B J &MBR &LIBR &OBJTYPE) 

DCL VAR(&OBJ ) TYPE(*CHAR) LEN(IO) 

DCL VAR(&MBR ) TYPE(*CHAR) LEN(IO) 

DCL VAR(&LIBR ) TYPE(*CHAR) LEN(IO) 

DCL VAR(&OBJTYPE) TYPE(*CHAR) LEN(7) 

ALCOBJ OBJ((&LIBR/&OBJ &OBJTYPE *EXCL &MBR)) WAIT(O) 

MONMSG MSGID(CPF1002) EXEC(SNDPGMMSG MSG('Object in use')) 

ENDPGM 
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by Openbbs Contributor 

Selected from DataNetwork's electronic bulletin board 
From: B. E. of San Antonio, TX To: All 

We are trying to use direct printing on the AS/400. In all the manuals all they talk about is 
spooling. I've heard it can be done but can't find any information about it. We use direct printing 
for all check printing and for check and forms alignment. I've heard it has something to do with 
routing entries. If anybody has any information about it, please leave a message. 

From: C. P. of San Mateo, CA To: B. E. of San Antonio, TX 

If you can get into the CL programs that control the printing, you can add an OVRPRTF 
(Override with Printer File) command, with an option of SPOOL(*NO). 
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by Openbbs Contributor 

Selected from DataNetwork's electronic bulletin board 
From: J. L. of Los Angeles, CA To: All 

After going on the AS/400 I decided to take advantage of being able to use more than two 
characters for our workstation ID's. It has allowed me to be more descriptive of each 
workstation. I am using four characters for each WS. However, I have OCL that uses the 
SNDBRKMSG command. I substituted ?WS? for the workstation message queue parameter and 
it worked great until I renamed the displays. When I displayed the value being passed to the WS 
parameter, it showed the old two-letter ID even though it no longer existed in the system. I plan 
to write a CL program to get around this but I'm still curious as to why this happens. My users 
are in S/36EE and my QDEVNAMING value is set to *S36. 

From: A. T. of Spotswood, NJ To: J. L. of Los Angeles, CA 

When a user is signed on to the S/36 environment, he uses the Workstation IDs from your 
"System/36 environment configuration." To view this, type DSPS36. It will show you the 
AS/400 WSID (i.e. DSP01), and the S/36 Id (Wl). As far as I know, all S/36 environment 
procedures that use ?WS? will retrieve the two-letter naming convention. You can change these 
with the CHGS36 command. 
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by Openbbs Contributor 

Selected from DataNetwork's electronic bulletin board 
From: L. J. of Grand Rapids, MN To: All 

AS/400 batch jobs using the JOBQ command in the S/36EE are directed to the QBATCH job 
queue. There is no way to change this as IBM has hardcoded this into the system in order to 
emulate the single JOBQ available on a S/36. Our operation utilizes many different S/36 
environment applications, and it would be a great improvement if each application could have its 
own JOBQ. Has anyone discovered a way to provide multiple S/36EE JOBQ's? 

From: E. M. of Torrance, CA To: L. J. of Grand Rapids, MN 

I'm no AS/400 expert (I don't have one yet) but I've read that in the S36EE you can intermix S/36 
and AS/400 commands. Specifically, you can place AS/400 commands within a S/36 procedure. 

This is good news to you. Instead of coding your S36EE procedure like: 

// LOAD XYZ // FILE NAME-FILEEDISP-SHR // RUN // JOBQ ,PROCl 

...why don't you code it l ik e this: 

// LOAD XYZ // FILE NAME-FILE EDISP-SHR // RUN // SBMJOB ... 

The last line is the "submit job" command (native AS/400) which will be much more flexible 
than the // JOBQ statement. Check it out—it might be the answer to your problem. 

From: R. L. of Mt. Kisco, NY To: L. J. of Grand Rapids, MN 

You might look into using JOBQ priorities. The S/36 really had 5 jobques—priorities 1-5. On the 
AS/400, you actually have more, namely 9 priorities. You can set them to either single-thread (1 
job executing at a time) or multiple procesing. The CHGJOBQE command gives you a lot of 
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control over the options. I've found it to be much more flexible than the native S/36 JOBQ. 
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by Openbbs Contributor 

Selected from DataNetwork's electronic bulletin board 
From: A. T. of Spotswood, NJ To: All 

I am using group jobs on my AS/400, and I want to be able to pass data in between them. When 
the programs used to be on the S/36, my procedure would end one program, and call up the 
other. With group jobs, however, the job doesn't really end, which means that the LDA does not 
get updated by RPG (RPG updates changes to the LDA when LR is set on). Is there any way to 
force the LDA to be updated on every cycle? 

From: C. P. of San Mateo, CA To: A. T. of Spotswood, NJ 

Look into these RPG opcodes: IN, DEFN, OUT. You should be able to control input/output to 
the LDA with these. So, I suppose you could put IN at the top of the program, OUT at the 
bottom to handle programs in the cycle. 

From: A. T. of Spotswood, NJ To: C. P. of San Mateo, CA 

I took your advice about a week ago concerning updating the LDA at every cycle in RPG by 
using the Hike DEFN operation. During testing, I was able to update the LDA everytime. 

However, when I "go live" and run the jobs as part of a group, I have problems. When I suspend 
one job and transfer to the other (TFRGRPJOB), the LDA is blank. Is it possible that during 
group jobs that each job maintains their own LDA? 

From: C. P. of San Mateo, CA To: A. T. of Spotswood, NJ 

I don't have much experience with group jobs, but I suppose that each job would have it's own 
LDA. I guess, in this case, you would be better off creating your own Data Area object, and 
reference that in each of the programs. A data area object, other than the LDA, should be 
available to any job in the system. You may need to devise some method to keep a data area 
unique to a user (similar to the LDA), but that should be fairly easy to do. 
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From: A. T. of Spotswood, NJ To: C. P. of San Mateo, CA 


I did figure out what was happening regarding the LDA. I was able to write out the LDA at every 
RPG cycle using DEFN. The problem was that I was using IP on my Screen outputs (converted 
RPGII program) The LDA fields weren't being read in before the IP output. I changed my 
WORKSTN file to Console Full-procedural (CF), then set on an indicator and went to the end of 
calcs using a one time loop. It works OK now. I did start to experiment with Data Areas, but 
didn't get them to work perfectly. What are the advantages to Data areas over LDA? Is a data 
area like a file? Does it retain its data after the CRT is powered down? 

Lrom: C. P. of San Mateo, CA To: A. T. of Spotswood, NJ 

Glad you could correct your LDA situation. Data areas shouldn't present any special problems, 
you can use DELN/IN/OUT with them, plus there are a couple of CL commands that you can use 
with them. I really don't know of advantage/disadvantage of a Data Area over LDA. A Data 
Area, though, can be accessed by any job in the system, but I presume the LDA is used only 
within a job (I haven't used the LDA on the S/38 or AS/400, so I am "fuzzy" on this. (Help, 
somebody). As far as Data Areas themselves, I've heard them described as "one record files." 
They do retain their data, as long as you've updated them before end of job (that is, use the RPG 
OUT op, or the CL CHGDTAARA). To me, it's kind of a toss-up, using DTAARA over 
"control" files. I seem to use each, half of the time. You most typically would see DTAARA 
being used for sequence numbers, etc. That is, your program needs the next number, gets it, then 
updates the DTAARA. I suppose there are advantages of DTAARA over 1-record files, in terms 
of machine resources used, but that's beyond my knowledge. By the way, when I do use 
DTAARA, if there is more than one field in it, I create a "dummy" physical file definition, so 
that I can use an externally defined data structure to map the contents of the Data Area. 

Lrom: A. T. of Spotswood, NJ To: C. P. of San Mateo, CA 

We are using group jobs for each salesman (about 10-12 active all day). The LDA is used to pass 
data between one of three group jobs. If we were to use data areas, wouldn't each workstation 
need its own Data Area name? I am using the LDA now, but I have since learned that the 
CHGDTAARA and DSPDTAARA commands modify and display the LDA. DataNetwork has a 
great program that updates the LDA in their RESOURCELIBRARY which I did convert to 
native. 

Lrom: C. P. of San Mateo, CA To: A. T. of Spotswood, NJ 

Yes, you could set up data areas that are named the same as the terminals. If you did that, you 
could use the job name from RTVJOBA to figure out which Data Area to use with the terminal. 
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by Openbbs Contributor 

Selected from DataNetwork's electronic bulletin board 
From: A. T. of Spotswood, NJ To: All 

I just wrote my first screen program using subfiles, and I am running into a problem. Normally, a 
screen would have a header displayed, i.e. CUSTOMER SRCH SCREEN, then column 
headings, then the data. After 18 lines of data, can I display function key legends on line 24? 
Anything that I put below the subfile data causes an error that says "Subfile control record 
overlaps records." Any help would be appreciated... 

From: C. P. of San Mateo, CA To: A. T. of Spotswood, NJ 

You will have to define anything that appears below the subfile records as a separate record 
format. In your case, a "one-line" record format that starts on line 24. When you do your screen 
output, you can WRITE that format first, then EXFMT your subfile control record. You may 
have to use the OVERLAY keyword so that the line-24 format doesn't get erased. 
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by Openbbs Contributor 

Selected from DataNetwork's electronic bulletin board 
From: E. R. of Fair Lawn, NJ To: All 

Does anyone know how I can print the Message file where only the message number and the first 
and/or second-level message text will print? I do not want to see any of the other information at 
this time. 

From: K. C. of Chestnut Hill, MA To: E. R. of Fair Lawn, NJ 

The command to print out the message file is DSPMSGD. After you have pressed CMD 4 to 
prompt for the parameters, the parameter marked "lower value" will be *ALL. "Message file" is 
the name of the message file you want to see, and "library" is the library in which it is located. 
The parameter marked "detail," you will fill in with *BASIC; output will be * PRINT. This will 
produce an output file that will show you the MSGID, SEVERITY, and MSG. If you want to see 
the second-level messages, you can change the DETAIL parameter to *FULL. But, this will also 
show you other info such as DATA TO BE DUMPED etc. There might be another way to do this 
also, but this is pretty easy. 
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by Chris Peters 

Data Communications - What is It? Who needs It? 

Fact is, any passage of information within an organization is data communication. The methods 
for the information exchange can be direct conversation, written words and numbers, pictures, 
graphs, etc., using language, paper, a video display, or the phone. When you think about it, a 
great deal of effort and expense is expended within almost any business for data communication. 

The Rules of Business and Network Design 

The manner in which your business operates will define how information must flow, which in 
turn will define your data communications network. Before you can properly design a network, 
you must first identify the rules of business that it must serve. 

All too often, the reverse is true; hardware or software is allowed to determine how business is 
done. In other frames of reference this would be intolerable. For example, would you turn away 
business because you didn't have enough telephones? Would you limit your company's growth 
because you had run out of employee parking? Of course not. The rules of business are more 
important than phones and parking; and they're more important than computers and programs. 

Increasingly, we in MIS are in the solutions business and the users are our customers. The 
product we provide must meet the user's needs if we expect it to sell. Therefore we have to know 
what those needs are. The days of heads-down code pounding are over. 

Define the Rules 

Forget files. Forget coding. Forget backups and upgrades and maintenance, and focus instead on 
what people do and how they do it. What happens, and when? Who is where, and how do they 
interact with the others? In short, what is the style and type of data communication? 

A more difficult target is one that moves — growth. Determine as best you can how much and in 
what ways your business will change. 
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A rule is a business requirement, not a matter of convenience. Be stingy with them and keep 
them as simple as possible. 

Compromises due to reality have their place in the network-design process, but for now, 
concentrate on identifying your goals. 

Determine How Information is Shared 

This is important. Many powerful new tools may or may not be available, depending on how 
users share information. Does one remote site depend on information from another? If so, how 
fresh must the information be? For instance, a hotel reservation system requires that all sites have 
immediate access to transactions performed at all other sites. This requirement may be best 
served by constant connections and a single database within a single host (or a DDM 
environment, as will be explained later). In contrast, each branch warehouse of a hardware 
distributor may be able to function nicely with only hourly updates of transactions performed at 
other branches. There are many more options available in setting up a network under this 
scenario than in the former. More about that later. 

The Most Frequently Heard User Complaint 

You guessed it. Poor response time. A close second is poor batch turn-around time. And it's 
understandable. You may avoid an otherwise good restaurant because the service is slow or you 
may frequent a particular barber shop just because you don't have to wait. The same feelings 
hold true for someone at the other end of a remote connection. Slow response breaks the user's 
rhythm, wastes his/her time and the company's money. 

Determine response time required by each business entity within your company. For example, 
users taking telephone sales orders from customers may require one second responses while 
other users can get by with 2-5 times that. 

Identify peak cyclic periods such as month-end close, physical inventory, and audit time, and 
define the corresponding response and turn-around time rules for each. Don't worry about how 
you're going to accomplish these things now; remember you're only defining the rules at this 
point. 

Measure Data Traffic 

This is a tough one. You can't use SMF or CSNAP to measure the volume of data traffic going 
through your remote system until you have a remote system. Nevertheless, knowing how much 
data traffic to expect is vital to the decision making process. OK, so you'll have to guess. A 
pretty good guide is to figure about 2000 characters transmitted and received every time a user 
presses the enter key. 

Much can be done to reduce the data volume, such as eliminating redundant transmission. 

Expect the Unexpected 

Experience shows that the unusual is usual. Changes and problems are the rule rather than the 
exception. Whether the cause is carrier-facility failure, equipment breakdown, a power outage, or 
sun spots, communication interruptions will happen. Well-defined business rules will take this 
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factor into account. 


What effect will a break in communications have on business? To what degree are functions 
impaired by network downtime? How much downtime is tolerable? How much does downtime 
cost? 

Conversely, consider that there may be unexpected uptime. Do users often work evenings? 
Weekends? Are your remote users in other time zones? 

Other Communication 

Get a quantitative grip on other forms of internal communication within your organization. You 
may find significant amounts of voice, fax, or telex communication taking place between sites at 
a correspondingly significant cost. You may be able to trim that expense by shifting some of 
these activities to your network. You may also be able to "gang" your needs together and save 
some bucks. 

Security Is What You Make It 

Particularly in S/38 and AS/400 environments, you can get about as clever as you want in 
controlling system access and user authority. To define this, you'll have to draw a balance 
between reasonable security and reasonable convenience. Additionally, these environments offer 
object authority. That is, authority to any file, program, command or device description can be 
assigned to a user or group profile at the usage, management, or existence level. 

It's a good idea to keep transparent as much of the authority-checking process as possible. For 
example, rather than set up multiple layers of password access, define a group profile to which 
all remote users belong, and then define remote devices with operational rights granted to the 
group profile only. That way, only functions authorized to the group profile may be carried out 
from a remote device, because only users associated with the group may sign on—all transparent 
to the user. 

Local, Remote, Peer, Source, Node and Target 

I suspect that definitions of local, remote, peer, source, node and target devices are not new to 
you. However, in the spirit of cooperative processing, existing concepts become ill-defined. 
What's remote to you may be local to someone else. 

Local devices are those that are attached to a CPU directly by twinax cable, a twisted pair wire or 
the like. Remote devices are those that require a carrier like AT&T to make the connection. 
Naturally, users of local devices enjoy the advantages of superior response time, the absence of 
communication frailty, and of course, no bills. 

A peer device is simply one with its own CPU and program base that has been configured as 
such. When multiple S/3Xs or AS/400s are connected, each computer sees the others as peers. 
Within a peer-to-peer setup, perspective among the systems is maintained by the terms "source", 
"node", and "target." The CPU that is local to you is your source system. Any other peer device 
in the network is a node. Should you wish to communicate with a specific node, that node is 
called the target system. 
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Cooperative Processing 


If you've been following IBM's announcements, you've no doubt encountered the term 
"cooperative processing." The plan is to create a network architecture and supporting software 
that will allow you to manage data across multiple systems as well as "port" applications to a 
device that is local to the user. "Porting" means moving non-machine-specific program routines 
from one processor to another. This can be as simple as running up-front editing and screen 
processing on an intelligent workstation (a PS/2 springs to mind), thereby freeing the host from 
that chore and severely reducing data transmission. A more complex situation develops when 
porting is coupled with distributed data management. 

Logic dictates that if these ported applications are to run on a range of systems, they had all 
better run the same. IBM has established standards for function and appearance of all the 
software they're going to sell through the coming years. These standards, together with the new 
network architecture, are called System Application Architecture (SAA). 

As SAA and cooperative processing become a reality, you will have more options available. 
You'll be able to build a leaner, faster network. (You'll also be sending less money to AT&T and 
more to IBM—but that's another story.) 

Nuts and Bolts — Lines and Hardware 

Mr. Natural says, "Use the right tool for the job!" Truer words were never spoken. But before 
you can do that, you have to know what the primary tools for communications solutions are. 

Communication lines are the circuit facilities which cover the distance between peers, or the 
host, and the remote site. There are several types, each with its own cost and performance virtues 
and shortcomings. Leased lines can be considered here to be full-time, circuit facilities provided 
by a communications company. This is like a 24-hour-a-day, long-distance phone call, except for 
data, not voice. 

Leased lines are also called "private" lines, meaning that you always have a link, but the circuit 
may involve public-line segments. In a long link, multiple local "telcos" route the circuit through 
their facilities. As you would expect, this involves much coordination of effort and can take a 
couple of months to set up. Fortunately, it's all handled by the communications company you 
choose. 

Analog lines are traditional tone-like carriers of a translated (modulated) computer signal. A 
standard link to DataNetwork BBS, Prodigy, or Dow Jones is an example of an analog line. They 
can be leased or dial-up. 

Digital lines are special four-wire circuits that preserve the on-or-off quality of a computer signal 
through the carrier's part of the link. AT&T calls their facility Digital Data Service (DDS). 

Packet networks are shared lines. Data is sent over a private line segment to the nearest carrier 
facility, "packetized" and addressed much like mail and sent along a public circuit. When 
received at a carrier facility near the destination site, the data is "de-packetized" and sent the 
remaining distance over another private segment. 
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Switched or Dial-up lines are really regular voice phone lines that are carrying data. The 
advantages over leased lines are that you can dial-up from anywhere, multiple users can share the 
same system access, and you're only charged for the actual time of the connection. The 
disadvantages are that dial-ups can only service one controller, are generally slower, the 
connections are more tenuous and prone to dropping, and the cost per minute is significantly 
higher given equally long distance. 

Other types of broadband communications methods exist such as a rooftop to rooftop satellite 
link, but the implied high volume of data doesn't really apply to mid-sized business applications. 

Modems perform the translations between the computer's digital signals and those of an analog 
line. 

CSU/DSUs are like modems but whereas modems go on the ends of an analog line, CSU/DSUs 
go on the ends of a digital line. 

Controllers are what the computer expects to find at the other end of communication links. Up to 
nine devices (workstations and printers) can be attached locally to a controller. The host sends all 
the signals for those devices to the controller which in turn sorts them out by the device address 
and passes them on. Examples of controllers are the IBM 5294 and 5251-model 12 (controller 
and workstation in one). 

APPC (Advanced Program-to-Program Communications) is IBM data-link support software that 
allows peer devices to communicate. 

APPN (Advanced Peer-To-Peer Networking) is data routing support for two or more APPC 
systems that are not directly attached. 

DSPT (Display Station Pass Through) is an APPC function that lets users on a source system 
sign on to a target system. DSPT is very handy and relatively easy to set up. 

Journaling is a utility available on the AS/400 and S/38 that creates before and after images of 
changed database records. You would use journaling to perform batched updates to a database 
that resides on another machine. 

DDM (Distributed Data Management) is support for network files. Network files are made up of 
records that are available across multiple-peer devices. You would use DDM to create a real¬ 
time environment over physically separate databases. 

5250-Remote emulation allows a PS/2 or PC to appear to a S/3X or AS/400 host as a controller 
with one or more workstation and optionally printers attached. This technique is very cost 
effective when only one or two tubes are needed at a remote site. Rather than installing a 
controller, workstation, and twinax printer (all expensive pieces of gear), you can equip a PS/2 or 
PC with a PC-type printer and emulation to do it all. Further, the PS/2 can still perform stand¬ 
alone functions. There is a trade-off, however, in that each one of these PCs counts as a 
controller to the host. The maximum number of controllers that the host can operate efficiently 
on one line is eight. After that, CPU resources begin to be used to handle the load. 

Async to SDLC protocol conversion is another method that lets async devices (like a PC or a 
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VT100 terminal) communicate with a S/3X or an AS/400. The sequencing rules for traffic and 
device management are called protocol and there are several conventions. AS/400s and S/3Xs 
operate under SDLC (Synchronous Data Link Control) or X.25, whereas PCs and the like 
commonly communicate asynchronously. You would use this setup to allow anyone with a PC, a 
cheap modem, and a password to access your system. 

Front-end control processing is a tool that takes the strain off an overworked host. A control 
device like an IBM (who else) Series/1 can assume the responsibility of communications control. 
Keep this in mind in case you ever get backed into a comer. 

ISDN (Integrated Services Digital Network) systems combine data and voice communication 
over the same circuit and are now becoming a reality. But they're complex and new. Unless you 
enjoy living on the leading edge, they warrant much consideration. 

There is considerable overlap of function among these tools—but even though many roads lead to 
Rome, the wise traveler selects the best route. 

You Get What You Pay For - Or Do You? 

Communication is expensive. Take a look at your company's regular voice phone bills. 

Surprised? Data communication expense can run into the tens of thousands per month, easy. 

Flaws in the network design can be extremely wasteful. Spending more and getting less is very 
common even in the simplest of networks. 

You Can Get Help 

If your network needs are complex, it's best to bite the bullet and hire an independent 
communications consultant. These folks don't come cheap, but you can easily waste more money 
on a less-than-optimum network. 

Along with many good communications consultants, the carrier companies themselves offer to 
study your configuration and data traffic and make recommendations. They have access to 
modeling utilities and can be quite helpful. Of course, they're going to recommend solutions 
within their own company's offered services. 

Very large and diversified applications may lend themselves to an interface and control network 
like AT&T's Information Systems Network. 

The Communications Carriers 

There are several companies that want your communications business, each, I'm sure, quite 
superior to the others. Again, your rules of business will help you make the best selection. 

Most domestic long-distance lines are owned by AT&T. Other packet carriers like Western 
Union or GTE Telenet lease AT&T lines at a discount and build a public network. AT&T once 
had the only digital facilities available, but their competition is now offering services in 
increasingly wider areas. 

It's important to understand how AT&T and the other carriers charge for their services because 
they differ greatly. 
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AT&T charges you for the host drop, each remote drop on the line, engineering facilities that 
link each telco segment, and for mileage measured in airline miles. There is no traffic-volume 
charge. 

Packet networks typically charge for the host drop, each remote drop, modems, control facilities 
and for data traffic. The traffic charge may be figured any number of ways, usually a flat rate for 
a certain number of kilo-packets and so much per kilo-packet after that. There is no charge for 
mileage. 

Just Around Town 

Toll-free, high-speed, dial-up links are fairly stable and the best deal going, because, as far as the 
phone company is concerned, it's a local voice call. The cost savings may make up for the 
occasional annoyance of having to reconnect. On the surface, this solution is limited, but keep it 
in mind when setting up distributed CPUs. You may be able to cut the data carrier out of the 
picture at some of your sites. 

Infrared is an option if your link is within direct line of sight, like across the street between 
rooftops. 

A Simplified Example 

Ignoring all other considerations for the moment, let's say your host is in Seattle and you want to 
establish a full-time link carrying a moderate amount of data to four offices around Spokane. 
Your best bet would be to order a leased, analog line from AT&T because the distance charge 
from AT&T together with the facility and drop charges don't equal the more expensive drop 
charges from a packet company. Also, intrastate, analog-line rates are quite reasonable and 
reliable because the same local phone company takes care of the whole circuit. In contrast, if the 
offices you want to link are in Baltimore, AT&T's mileage charge would make a packet network 
more cost effective. Then again, if the volume of data is high, or if you want to link to a few 
more sites around Baltimore, the packet network's charge for traffic and its higher drop charge 
will swing favor back to AT&T. 

Who Provides What? 

You must have certain features installed within your CPU in order to communicate. On the S/36, 
you need a communications adapter, EIA interfaces, and either multi or point-to-point lines. The 
AS/400 comes with at least one communication line as part of its maintenance and diagnostic 
system. You can determine what's on your system presently by your machine-history listing in 
your CE manual, or by checking with IBM. 

The local telephone company will provide the circuit facilities up to the "D-mark." The D-mark 
is the modular plug or connection block that is attached to the wall. This is the point that 
separates DCE (Data Communications Equipment like telco facilities) from DTE (Data Terminal 
Equipment like controllers, line-sharing interfaces, emulations cards, workstations, printers, etc.). 
Generally, the carrier is responsible for the circuit up to the D-mark. After that, it's your 
responsibility. 

Naturally, you provide DTE stuff. With some carriers (AT&T for one,) you must also provide 
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the modems (analog lines) or CSU/DSUs (digital lines). Most packet carriers supply their own 
modems. Additionally, analog lines require a signal amplifier called a channel interface which is 
provided by the local telco. 

Finger Pointing 

The bane of many an MIS director has been the mix and match of multiple vendors' equipment 
within a system. When a problem occurs all-involved equipment vendors have a convenient 
excuse — each other. Getting the participants together to thrash out the problem is difficult and 
time consuming. Agreed, data communications is complex, and snap-fitted solutions across 
vendor lines common, but keep it simple wherever possible. 

Digital and CSU/DSUs vs. Analog and Modems 

Digital lines are fast, clean, reliable, and they permit non-disruptive testing and problem 
correction from a carrier-control facility. They're also more expensive than analog lines and not 
available in all areas. Digital lines are appropriate when operating at high speed with a strict 
downtime requirement across long distances. 

Analog lines are also fast and relatively reliable, but testing and problem correction can't take 
place while the circuit is in use. Frequently when a drop on a multi-point analog line goes down, 
all drops downstream from that point will also go down. Analogs are the most cost-effective 
solution for shorter hauls (1000 miles or less), particularly within a single telco. 

CSU/DSUs are likewise more flexible and reliable than modems and, surprisingly, less 
expensive. (See, you don't always get what you pay for.) As the number of drops on a long link 
increases, the cost disparity among modems and CSU/DSUs can allow you to justify the 
preferred, digital service. 

Line Speed vs. CPU Capability 

You might think that higher speed equals better remote-response time. There's another factor in 
the equation; that's the CPUs ability to perform the transaction once the transmission is received. 
This is analogous to a high-speed road with a traffic light at the end. It doesn't help much to zip 
down the road if you have to stop and wait at the light. 

Downtime and Recovery 

If you've been successful as a provider of business solutions, your applications are of genuine 
value. Their value can be measured by what happens when they're gone. 

Communication interruptions can last for minutes, hours or days. You must plan for them. 

Switched Network Backup 

For your more impatient users, consider installing regular outside voice lines and dial-up 
modems near the D-marks of a leased line. If (more like when) the leased line fails, you can 
quickly swap connections to the dial-up modems and re-establish a connection. Also, some 
modems have built-in switching capabilities. 
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Configuring Departments Across Multiple Controllers 

When more than one controller is in use at a single site, run half of the devices within a 
department to one controller and half to another. (This is a good idea with local workstation 
controllers, as well.) Rather than having a whole department's computer activity brought to a 
standstill by a controller failure, half the tubes would remain active (albeit in two departments) 
and transactions could limp along for awhile. Using a single controller with dual channels, you 
can configure across both sides to gain some advantage, but usually the controller will fail as a 
unit. 

Programming Considerations—AS/400 and S/38 

Problems can arise if a communications failure occurs when some file updates comprising a 
transaction have been performed but others haven't. AS/400 and S/38 interactive programs that 
update multiple, database files can make use of commitment control to roll back partial 
transactions. 

Limit the size of entry and update capable subfiles to a screen or two, and then perform the 
database updates. If you allow a remote user to key and roll many subfile pages, they can lose all 
their work in an ill-timed failure. 

Eliminating redundant transmissions will improve network performance. If the same screen is 
frequently being redisplayed to the user, transmit only the field values and screen attribute 
indicators. This can be accomplished through the use of the OVERLAY and PUTOVR at the file 
or record level, and OVRDTA and OVRATR at the field level of display file DDS, and 
RSTDSP(*YES) on the CRTDSPF command. 

The system will send displays to a remote workstation in one-third screen segments. The user 
sees halting screen segments displayed at nervous little intervals. To prevent this, 
DFRWRT(*YES) has become the default on the CRTDSPF command. This will hold the display 
in the workstation buffer until the whole screen has arrived and is present all at once. There is no 
improvement in performance except maybe on the user's part. 

While waiting for the screen to arrive, it's best to retain the current display rather than "going to 
gray." Specify the keyword KEEP at the record level. This allows the user to continue viewing 
the current screen while waiting for the next, and it renders a better-perceived response time. 

These programming notes for the AS/400 are intended for presentation purposes only. Please 
refer to the appropriate manuals. 
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Last month we dipped into the Structured Query Language (SQL) a bit, covering some of its 
history and emphasizing particulary that SQL is a computer language. 

Something Else 

We leaned on the concept that SQL is a computer language because of something odd we have 
noticed about the psychology of computer programmers. Specifically, we have noticed that a 
sizeable percentage of programmers allow themselves to be more impressed, and confused, than 
they should be by things that are represented to them as new and sophisticated. SQL is not alone 
in this respect, but it is a significant recent example. 

The point of comparison is always something familiar. To a typical midrange programmer, the 
most familiar thing is probably the RPG II or RPG III language. SQL doesn't look much like 
RPG II or III. It doesn't even look a whole lot like COBOL, though it is "getting warmer" 
compared to RPG. Many of SQL's operations are implicit rather than explicit. A certain aura of 
"leading edgeness" has been created around SQL by trade press coverage. The tendency, then, is 
to think of SQL as "something else." 

Cast Adrift 

This, in turn, seems to interfere with the ability of many programmers to absorb information. If 
you can convince yourself that a new thing has useful similarities to a familiar old thing, then 
you have a comfortable framework on which to hang information you pick up about the new 
thing. 

If you talk yourself out of believing the new thing fits any familiar pattern, though, everything 
about it will seem arbitrary. With no framework on which to hang the new information picked 
up, it just accumulates in your hands until you begin to overload, bobble and drop things. When 
everything is disconnected in this way — and when what information that sticks with you has a 
certain random quality about it — the new thing will stay unfocused. 
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We emphasized the point that SQL is a programming language, with many similarities to other 
programming languages, to reduce any air of mystery surrounding SQL. 

Generality Limits 

But, while definitely a computer language, SQL also has important differences from the more 
familiar programming languages to which we compared it. 

The most important such difference is that SQL is not really general purpose in the same way as 
RPG or COBOL. SQL started out as strictly a mechanism for formulating queries against a 
relational database. It was a formal computer language even then, but a special purpose one. 
Later, SQL was expanded to cover the related areas of defining and updating a relational 
database. Still a language, and still, as we shall see, special purpose. 

Within its special context of defining, querying and updating a database, SQL is quite a broadly 
applicable tool. But working with file data — however powerfully — is only part of what you 
expect from a genuinely general purpose programming language. 

SQL Doesn't Compute 

In addition to manipulating stored data, most programming languages also provide you with 
facilities allowing non-trivial computations to be performed on some combination of stored and 
freshly input data. In most such languages, you exercise control of these computations through 
use of statement types that direct the flow of execution in your programs based on the truth or 
falsity of testable propositions about your data. The programming language features that allow 
you to define these testable propositions are implementations or variations of the IF-THEN- 
ELSE, DO-WHILE, DO-UNTIL, and DO-CASE-OF mechanisms of structured programming. 

In a classical batch program, for example, you might read every record in some file and use such 
test and branch logic to chose records. Those you selected would supply the initial field values 
you wished to use in computations. Records not chosen would be bypassed as subsequent read 
operations were performed. SQL, being declarative rather than procedural or algorithmic in its 
syntax, does not allow you to code conventional test and branch logic. 

SQL Computation 

You can specify SQL UPDATE operations that perform complex computations to determine the 
new values for one or more fields in each fetched record of an answer table. A SQL UPDATE 
statement is much like the SQL SELECT statement used strictly to define queries, but with some 
extra syntax attached to define the computations that will yield the new values for the fields to be 
updated. 

The equivalent of reading every file record and applying test and branch logic to sift out the 
records you want to change can be achieved in a SQL UPDATE statement using the relational 
select and project operations implicitly specified via conditions in the WHERE clause. If you 
want to update the widget file records for blue widgets only, your WHERE clause should say 
WHERE COLOR = BLUE', WHERE COLORCD = V B', or something similar. A SQL WHERE 
clause acts like, among other things, the include/omit logic of a sort specification or the record 
identification logic of an RPG input specification. It defines what records will show up in the 
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intermediate answer table. 


Limits Of SQL Computation 

Even allowing for the UPDATE statement, however, SQL cannot straightforwardly do things 
equivalent to what you can accomplish in a more familiar programming language using test and 
branch logic. The first limitation is that all records selected for update by a SQL UPDATE 
statement will have the same sequence of operations applied to the fields for which you coded 
value-changing computations before these new values are written back to the database. If you 
want to add ten percent to the commission rate of all salespeople who have sold 150% or more of 
their quotas, for example, you can write a SQL UPDATE statement to do it. Such a statement 
would probably look much like the one shown in Figure 1. 

For the conditions stated to apply to the Figure 1 example, SQL is more terse and convenient 
than conventional test and branch programming. But this is not invariably true. Suppose you 
wanted to boost commissions ten percent for those who hit half again their quota — just as in our 
first example. Now suppose you also want to give an additional ten percent boost to the 
commissions of any superstars who sell double their quotas or more. The straightforward way to 
do this would be to filter the sales rep file using the 150% of quota criterion, then use test and 
branch logic — a simple IF-THEN-ELSE would do — to control whose record gets which 
commission boost percentage. A need to filter records from a file with one set of criteria, then 
look at additional criteria to control detailed update computations is something very frequently 
encountered in system design. 

The Price Of Independence 

You can do such things purely in SQL, but it may not be a good idea. Figure 2 shows the first 
visible liability of such an approach — there are now two UPDATE statements instead of one. 

The equivalent test and branch logic, in this case, is only a two-pronged IF-THEN-ELSE 
structure. 

In general, of course, you can code quite complex test and branch logic using conventional 
programming languages. For every outcome destination in nested IF and/or CASE logic, you 
need to code a separate SQL UPDATE statement just to approximate logical equivalence of 
function. 

Even for simple selection criteria, as in the Figure 2 example, this adds a lot of code. Much of the 
code bulk accrues because you have to substantially repeat the selection criteria in each such 
SQL UPDATE statement. Lower-level IF structures in a multi-level IF-THEN-ELSE complex 
don't have to repeat the tests made by higher-level IFs. The path of execution never reaches these 
lower-level IFs unless all the appropriate conditions tested by higher-level IFs are true or false in 
just the proper way. SQL statements, though, are independent of one another. The second 
UPDATE statement in Figure 2 knows nothing about what the first may have found or done 
when it executed. 

Yeast-growth Curve 

As you may appreciate by now, the more complex a set of IF-THEN-ELSE logic you attempt to 
duplicate using independent SQL statements, the greater will be the size and complexity of each 
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of these individual statements. You would, of course, also increase the total number of SQL 
statements needed at the same time. Every additional level of nesting in an IF-THEN- 
ELSE/CASE structure can as much or more than double the number of SQL statements needed 
to do the same job. 

Even for very simple IF logic, then, setting out to create equivalent SQL UPDATE statements 
would soon begin to strike you as a lot like writing punishment sentences on the blackboard in 
grade school. To make matters worse, each SQL UPDATE would be slightly different, unlike 
those identical grade school iterations of "I will not chew gum in class" or whatever. 

Grind, Grind, Grind 

All of these redundantly specified selection tests cost you in terms of object code size of the SQL 
code too. If such duplicative code is embedded in a compiled application program, the extra 
executable code will drive up the likelihood of virtual memory paging activity by that program 
and proportionally slow its execution. 

A still greater consequence of using pure SQL in place of test-and-branch coding is that you 
invisibly duplicate a lot of file processing steps. To take the example in Figure 2, the execution 
of both UPDATE statements would require the SQL query processor to make two complete 
passes over the SALESREP file — two UPDATES, two passes. If you had some way to select 
both 150% Club and 200% Club member records on a single pass, then decide the particular 
updating for each using something like test-and-branch logic, you could make better use of your 
machine's time. 

Errors 

There are even worse things than code bulk and slow processing lurking in wait, however. Figure 
3 shows a sequence of two SQL UPDATE statements that appear to accomplish the same stated 
commission boosting job as Figure 2. The first adds 10% to the commissions of the "150% 

Club." The second adds an additional 10% to the commissions of the "200% Club." 

When you dress, you put on your underwear and socks first. Careless SQL programming can 
leave you — metaphorically speaking — with your shorts on the outside. Inadvertent overlapping 
conditions can make the apparently obvious SQL code produce the wrong results. Test and 
branch logic allows you to separate update computations into mutually exclusive sets, but 
consider Figure 3. All sales reps who sell 200% or more of their quota also sell 150% or more of 
that same quota. Things cannot be otherwise. The first SQL UPDATE, then, will bump up rates 
for the 200% Club as well as the 150% Club. 

But then that second SQL UPDATE will do its stuff. Boosting commission rates by 10% twice is 
not the same as boosting the same original rates by 20% once. The base for the second 10% 
boost is already 10% larger than it started out. 


l.Ox 1.1 = 1.1 


1.1 x 1.1 = 1.21 

If you used the Figure 3 SQL code, 200% Club members would get a windfall commission boost 
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of one percent over and above what you intended. 

Other Omissions 

So SQL is no great shakes at computation. What else can't it do? Format its output for 
presentation is what. SQL has no statement types for specifying the format of printed or 
displayed output in much detail. General purpose programming languages have output 
specifications, EXFMT statements, PRINT statements, FORMAT statements, etc. Not SQL. 

Symbiosis 

Familiar, general purpose programming languages don't contain relational file manipulation 
operators. SQL — powerful though it is in the complex query and update sphere — contains no 
provisions for test and branch computations on selected records nor any way to specify precise 
display or print formats. The obvious thing to do is — somehow — slip SQL into conventional 
programming languages as a set of functional extensions. Doing this trick requires, in turn, that 
four particular problems be solved. 

Scrambled Syntax 

The first is reconciling SQL's "look" with that of the language you want it to fit within and work 
with. RPG, COBOL, Pascal, etc., all have extensive legal syntaxes already defined. The SQL 
syntax differs from all of these in many irreconcilable ways. Re-doing a compiler to directly 
make sense of mixed host language/SQL source code would be difficult if not impossible for 
most target languages. It has proven far easier — and more reliable - to require that you embed 
SQL statements as blocks within host language programs, set off from native language 
statements by easily indentifiable delimiters. 

Figure 4 shows what these embedded SQL block delimiters look like in RPG programs. The first 
line of a SQL statement must begin with EXEC SQL, preceded by a slash character (/). The 
remainder of that first line can be occupied by part or all of the SQL statement, proper. The last 
line of a SQL statement must be END-EXEC, also preceded by a slash. Any intervening lines 
needed to hold parts of a lengthy SQL statement must have plus signs (+) in column 7. You can 
code SQL statements, bounded by the proper delimiters, in any part of an RPG program's 
calculations — detail, total or subroutine. 

Playing With Blocks 

Compilers could, in theory, be written that would take these delimiters as signals to switch the 
set of syntax rules in force from host language to SQL and back again. But an approach that is 
simpler, and just as effective, is to build SQL language preprocessors that translate SQL 
statements into data items and external subroutine calls in the syntax of your desired host 
languages, whatever they may be. This technique enjoys the considerable advantage of not 
requiring that any modification whatsoever be made to your existing host language compilers. 

Match-ups 

The second consequence of "ghettoizing" SQL code in little neighborhoods inside your 
programs, is a need for some mechanism to let your programs communicate with SQL in a 
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precise way. Take a second look at the SQL code examples in Figures 1 and 2 and you can see 
the problem. The code in these examples is entirely specific, not general. The UPDATE 
statements prescribe one particular rate of increase in one field's value when another field's value 
is found to have a particular numerical relationship to a reference value. 

A general purpose computer language allows you to do broadly general coding. At a minimum, 
you need a way for those things which are hard-coded constants in the Figure 1 and 2 examples 
to be coded using variables instead. This is the difference between coding only a specific 
prescription and coding a general policy. 

Embedded SQL allows you to use suitably defined variables or data structures in place of 
column names or literal constants. You define these fields or structures in the usual ways in the 
host language part of any program that uses embedded SQL. You make references to these 
variables and structures by preceding their names with a colon (:) character wherever they appear 
in a SQL statement. Ligure 5 shows how you might recode the SQL example from Ligure 1 for 
more flexible use within an RPG program. 

Tiptoe Through The Tuples 

A third question needing settlement before SQL could peacefully coexist with your host 
languages was how those programs would deal with embedded SQL queries that returned answer 
files having more than one record. The host languages on the AS/400 have no I/O facilities 
designed to let you handle multiple records at once. 

The solution was to extend SQL a bit in a way that would allow your host language programs to 
handle multi-record answer files one record at a time. The most crucial of these extensions was 
the notion of a cursor. A cursor for a SQL-generated answer file performs exactly the same kind 
of current position pointing job that a screen cursor does on your workstation screen. A screen 
cursor tells you where the next typed character is going to go on your screen. A SQL cursor 
keeps track of which record from an answer file you will next read or update. 

SQL In Action 

The first part of Ligure 6 shows a SQL cursor definition. The name of the cursor is SREP. Note 
that a SQL DELINE CURSOR statement contains its own SELECT query definition. In this 
case, the query is designed to find all records for reps who have sold enough over their quotas to 
qualify for a boost in their commission percentages. The lowest threshold over quota to qualify 
for an award is 150%. You need to set the host variable MINOVR, then, to a value of 1.5 in the 
RPG calc specs before the query runs. The records you get this way will include those for 200% 
Club members as well as 150% Clubbers. The LOR UPDATE OL part of the cursor definition 
informs SQL that the COMMRATE field in each retrieved record is subject to modification. 

Note that a cursor definition, as shown in Ligure 6, is just that — a definition. DECLARE 
CURSOR statements are not, in SQL terms, executable. The query you specify as part of the 
cursor definition is actually evaluated and run when your RPG program executes a SQL OPEN 
statement for the defined cursor. OPEN SREP gets that ball rolling. CLOSE SREP disconnects 
the SALESREP file from your program when the latter is through processing the former. 

Once the query in the DECLARE CURSOR statement is run, you can read individual records 
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from the answer file using the SQL FETCH statement. The middle part of Figure 6 shows such a 
FETCH statement. It puts the three record fields, listed by their SQF names in the SEFECT part 
of the DECFARE CURSOR statement, into three corresponding host language fields. 

Shortfall 

Something worth noting here, is that, for now, SQF is less flexible in allowing record-at-a-time 
access to answer file records than RPG is in allowing record-at-a-time access to system files. At 
present, SQF only allows you to do sequential FETCHing from an answer file. Numerous 
suggestions have been made as to how SQF's syntax and behavior ought to be extended to allow 
reading backward as well as forward through an answer file, or to allow direct file-like random 
record access to such files, but neither the draft ANSI SQF standard nor any currently 
implemented IBM version of SQF contains such extensions. Too bad. RPG III programmers are 
used to READP (read previous) and direct file access. It would have been nice to have them both 
available to use with SQF answer files as well. 

Revision 

Meanwhile, back at Figure 6, you have queried and fetched. At this point your program should 
use test and branch logic to decide what commission boost a record's owner should get, then 
adjusting the commission rate in the host variable accordingly. You return to embedded SQF 
capabilities to write the updated value back to its file. 

The last part of Figure 6 shows the SQF UPDATE statement type that you use to do this job. 
WHERE CURRENT OF SREP just means update the record currently pointed at by the cursor 
SREP. This will be the record you just read with the FETCH statement. 

Smoke Detectors 

The final problem raised by embedding SQF statements in a host language program is exception 
handling. Reading a SQF answer file with FETCH operations, for instance, requires the same 
considerations of error checking and end-of-file processing that apply to conventional, sequential 
batch applications such as report writing. 

SQF communicates with a host language program through a SQF Communications Area 
(SQFCA). This is a predefined data structure containing various codes and flags. When you run 
the SQF precompiler, it automatically slugs code into your program to define the SQFCA. 

You specify exception handling with WHENEVER statements that check one or another of the 
codes and flags in the SQFCA. Figure 7 shows a WHENEVER statement of the form you would 
use for routine end-of-file processing. 

WHENEVER statements have a bit of both the declarative and the executable about them. The 
form of the WHENEVER statement is clearly declarative, an announcement of what will happen 
under given conditions. On the other hand, WHENEVER statements represent tests of those 
conditions which execute as the statements are encountered in the normal course of executing 
your programs. When the tested-for condition occurs, the WHENEVER statement transfers 
control to the designated label in your host program. 
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WHENEVER statements transfer control with a GOTO and not a subroutine call. This means 
your programs' error handling code cannot return control to whatever areas of mainline code the 
WHENEVERs reside in. This limitation injures your ability to write entirely structured 
programs. You are in good company here, though. No other programming language in common 
use for business applications has any better arrangement for exception handling. 

Back To School 

The SQL statements you embed in your application programs, of course, do not have to be 
limited to the relatively simple. A simple-sounding application example will show you how SQL 
can get a bit baroque. 

As a starting point, we pick the school-related database example we started last month (see 
Figure 8). There are some changes from that version to this. There is a new file for appointments 
with academic counselors, CNSELAPPT. The former FACULTY file is now EMPLOYEE, with 
both FACULTY and COUNSELOR being subsets of EMPLOYEE made available as separately 
named entities through use of SQL's view capability. 

A SQL view has most of the characteristics of an answer file produced by a SELECT query. 

Using views, you can specify "virtual" files that are defined in terms of the same select, project, 
join and union operations available to you in defining queries. 

Dialect 

Other changes were based on the somewhat more restrictive syntax of AS/400 SQL as compared 
to other implementations. We did not actually get any hands-on time with SQL to test last 
month's code samples. A few problems would ensue if those samples were tried as written. The 
AS/400 version of SQL wants fully qualified file names, for example. Nor can indexes and files 
share names as both are files in the eyes of the AS/400's database manager. 

SQL also requires that all data field definitions be declared either NOT NULL or NOT NULL 
WITH DEFAULT. Fields that cannot be allowed to have zero or blank contents should be NOT 
NULL. Other fields, specified as NOT NULL WITH DEFAULT, will have default values of 
zero or blank slugged in if your programs provide no non-zero or non-blank values to fill them. 
There is, evidently, no way in AS/400 SQL to specify a field that could have a legitimate null 
value. As the AS/400 database does not support nulls, this is apparently intentional. Thus, our 
advice of last month to standardize on NOT NULL WITH DEFAULT for most fields is made 
mandatory under AS/400 SQL. 

Schizophrenia 

The subject of null values, though, is not clarified at all by current IBM SQL manuals. The 
syntax requiring either NOT NULL or NOT NULL WITH DEFAULT on field declarations is 
documented. And in one place, the manuals flatly state that there is no support for null field 
values that are distinct from zero or blank. And yet, in numerous other spots in these same 
manuals, there are passages of text that concern themselves with null values and their handling. 

It looks very much as though the AS/400 SQL manuals may have been derived from clone 
copies of manuals for DB2 or SQL/DS and were perhaps not error-checked as carefully as they 
might have been during their modification to AS/400 form. We, at least, cannot think of any 
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other good reason for a set of manuals to be so internally contradictory. 

Trolling For Trouble 

Returning to the matter of an example application using our college or university database, 
suppose you want to look automatically for students who may be having problems with some of 
their classes. Academic counselors, obviously, would find this a useful ability. 

You decide that a student can be considered to be having trouble if he or she gets any grade of 
'D' or below in any course — a grade of 1.0 or less on a four-point scale. You further decide that 
any student who gets a class grade that is one whole grade level or more below his or her grade 
point average for the semester, is also having trouble, even if said low grade is above a T).' 

The SQL code in Figure 9 will find such students and pull out the student number and computed 
semester grade point average (GPA) for each. The query portion starts by joining the enrollment 
and class files on department code and class number. Resulting answer file records that apply to 
the year and semester contain a student number, which is simply retrieved, and a semester GPA 
which is computed. In the specified query, this computation is defined using an arithmetic 
expression in place of just a simple column name. Future fetches done against this query's cursor 
will pass the retrieved and computed data values along to a pair of host variables. 

Discrimination 

Something new to you in this query is the GROUP BY clause. GROUP BY causes SQL to treat 
the answer file of a query as though it were to be the input file to a batch process. Your answer 
file is sorted into groups that have a given value of one or more fields in common. In this case, 
each group consists of all enrollment/class records for a single student in a given semester in a 
given academic year. 

Something else new is the HAVING clause. You use the HAVING clause to define further 
retrieval conditions that will winnow out some of the groups created by the GROUP BY clause. 
In this case, you want only students who are having academic trouble in at least one class based 
on the criteria stated earlier. 

MIN and SUM in the HAVING clause are what SQL calls column operators. In the case of 
SUM, values of the field or expression inside the parentheses are added up for all records in each 
group. MIN examines the value of the field or expression inside its parentheses for each record 
in a group, and returns the lowest to your calculation. 

The combination of GROUP BY and HAVING makes this SQL query work like a batch sort and 
summarize jobstream. Only one record goes in the answer file for each suitable group of records 
turned up by the join and select operations coded in the WHERE clause. 

Make Appointments 

With a student number and semester GPA for every student showing signs of academic distress, 
you can use simple SQL INSERT logic elsewhere in the same program to write new records to 
the counselor appointment file, CNSELAPPT. Having given this file a unique index, any 
INSERT you try to do for a combination of student number, academic year and semester, will 
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succeed only if that combination is not already out there on your file. 

Such duplicate records might crop up if the program is run more than once per semester. Your 
program will run faster, in the usual case, if you can avoid doing explicit reads to test for existing 
records with keys matching new ones you are trying to add. Coding your program logic to 
always try adding new records, then using WHENEVER statements to abandon the effort in the 
event of duplicate key hits, is the way to be both safe and fast. 

How the year, month and day for seeing the counselor gets scheduled, we have left vague. 
Perhaps an automatic scheduling program munches on the new records in a CNSELAPPT and 
slugs in appointment dates it finds suitable. Perhaps you have, instead, elected to review and 
assign counseling appointments manually, interactively. 

Review Situations 

The SQL statement in Figure 10 is parameterized by counselor employee number, and calendar 
date. It is designed to pull out a fat wad of data about a student's classes. Most of the data needed 
for a fairly comprehensive screen display about a given student's situation is pulled together 
through this SQL query which joins seven files in all. 

About the only relevant data that didn't manage to squeeze into this big query were the first and 
last names of applicable faculty members. To pick up these odds and ends, in whatever 
application program contains your big query, you could also code a simple, single-record fetch — 
employing a SELECT statement — from the EMPLOYEE file via the FACULTY view. As the 
search key, you would use the faculty employee number that you got from the SECTION file as 
part of your big query. 

Conclusion 

While the look of the code will take some getting used to — especially by RPG programmers — 
you can combine the power of SQL and your favorite programming language to make programs 
having all the strengths of both. Our only word of caution is to be judicious. SQL is powerful and 
fun to play with. Under normal circumstances, things with such characteristics become objects of 
holy veneration by programmers. But don't try to do every file manipulation solely with SQL. 
There is a place, even yet, for test and branch logic in the processing of files. 

Figure 1 Single update 


Figure 1 
Single Update 

UPDATE DATABASE.SALESREP 

SET COMMRATE = COMMRATE * 1.1 
WHERE YTDSALES = QUOTA * 1.5 

Figure 10 Display information about a student's classes 

Display Information about a Student's Classes 

C/EXEC SQL 

C+ DECLARE BIGCHUNK CURSOR FOR 
C+ SELECT SCHOOL.CNSELAPPT.STUDENT#, 

C+ SCHOOL.CNSELAPPT.YEAR, 

C+ SCHOOL.CNSELAPPT.SEMESTER, 

C+ SCHOOL.STUDENT.FIRSTNAME, 

C+ SCHOOL.STUDENT.LASTNAME, 

C+ SCHOOL.ENROLLMENT.DEPTCODE, 

C+ SCHOOL.DEPARTMENT.NAME, 
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C+ SCHOOL.ENROLLMENT.CLASSNUM, 

C+ SCHOOL.SECTION.SECTION, 

C+ SCHOOL.CLASS.TITLE, 

C+ SCHOOL.ENROLLMENT.GRADE, 

C+ SCHOOL.CNSELAPPT.GPA 

C+ FROM SCHOOL.STUDENT, SCHOOL.DEPARTMENT, 

C+ SCHOOL.CLASS, SCHOOL.SECTION, 

C+ SCHOOL.COUNSELOR, SCHOOL.ENROLLMENT, 

C+ SCHOOL.CNSELAPPT 

C* 

C* Ensures retrieved data is only for the counselor 
C* running the program 
C* 

C+ WHERE SCHOOL.COUNSELOR.EMP# = :MYEMP# 

C* 

C* Join COUNSELOR view of EMPLOYEE file to STUDENT file 
C* on counselor’s 
C* employee number 
C* 

C+ AND SCHOOL.COUNSELOR.EMP# = SCHOOL.STUDENT.COUNSELOR 

C* 

C* Join STUDENT file to CNSELAPPT file on student number 
C* 

C+ AND SCHOOL.STUDENT.STUDENT# = SCHOOL.CNSELAPPT.STUDENT# 

C* 

C* Make sure only students scheduled to be seen taday 
C* are selected 
C* 

C+ AND APPT_YR = :YR AND APPT_MO = :MO AND APPT_DY = :DY 

C* 

C* Join CNSELAPPT file to ENROLLMENT file on student 

C* number, academic 

C* year and academic semester 

C* 

C+ AND SCHOOL.CNSELAPPT.STUDENT# = SCHOOL.ENROLLMENT.STUDENT# 

C+ AND SCHOOL.CNSELAPPT.YEAR = SCHOOL.ENROLLMENT.YEAR 

C+ AND SCHOOL.CNSELAPPT.SEMESTER = SCHOOL.ENROLLMENT.SEMESTER 

C* 

C* Join ENROLLMENT file to SECTION file on department code, class 
C* number, academic year, academic semester and class section number 
C* 

C+ AND SCHOOL.ENROLLMENT.DEPTCODE = SCHOOL.SECTION.DEPTCODE 

C+ AND SCHOOL.ENROLLMENT.CLASSNUM = SCHOOL.SECTION.CLASSNUM 

C+ AND SCHOOL.ENROLLMENT.YEAR = SCHOOL.SECTION.YEAR 

C+ AND SCHOOL.ENROLLMENT.SEMESTER = SCHOOL.SECTION.SEMESTER 

C+ AND SCHOOL.ENROLLMENT.SECTION = SCHOOL.SECTION.SECTION 

C* 

C* Join SECTION file to CLASS file on department code and class number 
C* 

C+ AND SCHOOL.SECTION.DEPTCODE = SCHOOL.CLASS.DEPTCODE 

C+ AND SCHOOL.SECTION.CLASSNUM = SCHOOL.CLASS.CLASSNUM 

C* 

C* Join CLASS file to DEPARTMENT file on department code 
C* 

C+ AND SCHOOL.CLASS.DEPTCODE = SCHOOL.DEPARTMENT.DEPTCODE 

C* 

C* Ensure that only ENROLLMENT file-derived data for classes meeting 
C* the "having trouble" criteria get selected for the answer 
C* file of this query 
C* 

C+ AND (GRADE 1.0 OR GRADE GPA - 1.0) 

C/END-EXEC 

Figure 2 Two-pronged If-Then-Else update 

Two-Pronged If-Then-Else Update 
UPDATE DATABASE.SALESREP 

SET COMMRATE = COMMRATE * 1.2 
WHERE YTDSALES = QUOTA *2.0 
UPDATE DATABASE.SALESREP 

SET COMMRATE = COMMRATE * 1.1 

WHERE YTDSALES = QUOTA * 1.5 AND YTDSALES QUOTA * 2.0 

Figure 3 Overlapping conditions 

Overlapping Conditions 
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UPDATE DATABASE.SALESREP 

SET COMMRATE = COMMRATE * 1.1 
WHERE YTDSALES = QUOTA * 1.5 
UPDATE DATABASE.SALESREP 

SET COMMRATE = COMMRATE * 1.1 
WHERE YTDSALES = QUOTA *2.0 

Figure 4 SQL block embedded in RPG 

SQL Block Embedded in RPG 

C RPG CODE 

C 

C/EXEC SQL 
C+ SQL STATEMENT 
C/END-EXEC 
C 

C RPG CODE 

Figure 5 SQL code from Figure 1 embedded in RPG 

SQL Code from Figure 1 Embedded in RPG 

C/EXEC SQL 

C+ UPDATE DATABASE.SALESREP 
C+ SET COMMRATE = COMMRATE * :BOOST 
C+ WHERE YTDSALES = QUOTA * :ABOVEQ 
C/END-EXEC 

Figure 6 Reading individual records 

Reading Individual Records 

C/EXEC SQL 

C+ DECLARE SREP CURSOR FOR 
C+ SELECT COMMRATE, YTDSALES, QUOTA 
C+ FROM DATABASE.SALESREP 
C+ WHERE YTDSALES = QUOTA * :MINOVR 
C+ FOR UPDATE OF COMMRATE 
C/END-EXEC 
C/EXEC SQL 
C+ FETCH SREP 

C+ INTO :COMM, :YTDSLS, :QUOTA 

C/END-EXEC 

C/EXEC SQL 

C+ UPDATE DATABASE.SALESREP 
C+ SET COMMRATE = :COMM 
C+ WHERE CURRENT OF SREP 
C/END-EXEC 

Figure 7 Exception handling with WHENEVER 

Exception Handling with WHENEVER 

C/EXEC SQL 

C+ WHENEVER NOT FOUND 
C+ GO TO WRAPUP 
C/END-EXEC 

Figure 8 School related database 

School Related Database 

CREATE DATABASE SCHOOL 
CREATE TABLE SCHOOL.STUDENT 

(STUDENT# DECIMAL(9,0) NOT NULL, 

LASTNAME CHAR(15) NOT NULL, 

FIRSTNAME CHAR(15) NOT NULL WITH DEFAULT, 

MAJOR CHAR(3) NOT NULL WITH DEFAULT, 

CLASSTAND DECIMAL(1,0) NOT NULL, 

COUNSELOR DECIMAL(6,0) NOT NULL) 

CREATE UNIQUE INDEX SCHOOL.STD 
ON SCHOOL.STUDENT (STUDENT#) 

CREATE TABLE SCHOOL.DEPARTMENT 
(DEPTCODE CHAR(3) NOT NULL, 

NAME CHAR(25) NOT NULL) 

CREATE UNIQUE INDEX SCHOOL.DEPT 
ON SCHOOL.DEPARTMENT (DEPTCODE) 

CREATE TABLE SCHOOL.CLASS 

(DEPTCODE CHAR(3) NOT NULL, 


Next 


Home 


Previous 








CLASSNUM DECIMAL(3,0) NOT NULL, 

TITLE CHAR(30) NOT NULL, 

CREDITS DECIMAL(2,1) NOT NULL) 

CREATE UNIQUE INDEX SCHOOL.CLS 

ON SCHOOL.CLASS (DEPTCODE, CLASSNUM) 

CREATE TABLE SCHOOL.SECTION 
DEPTCODE CHAR(3) NOT NULL, 

CLASSNUM DECIMAL(3,0) NOT NULL, 

YEAR DECIMAL(4,0) NOT NULL, 

SEMESTER DECIMAL(1,0) NOT NULL, 

SECTION DECIMAL(2,0) NOT NULL, 

BLDG CHAR(3) NOT NULL WITH DEFAULT, 

ROOM# DECIMAL(3,0) NOT NULL WITH DEFAULT, 

FACULTY DECIMAL(6,0) NOT NULL WITH DEFAULT) 

CREATE UNIQUE INDEX SCHOOL.SCT 

ON SCHOOL.SECTION (DEPTCODE, CLASSNUM, 

YEAR, SEMESTER, SECTION) 

CREATE TABLE SCHOOL.EMPLOYEE 
(EMP# DECIMAL(6,0) NOT NULL, 

LASTNAME CHAR(15) NOT NULL, 

FIRSTNAME CHAR(15) NOT NULL WITH DEFAULT, 

TITLE CHAR(15) NOT NULL, 

CATEGORY CHAR(15) NOT NULL) 

CREATE UNIQUE INDEX SCHOOL.EMP 
ON SCHOOL.EMPLOYEE (EMP#) 

CREATE TABLE SCHOOL.ENROLLMENT 

(STUDENT# DECIMAL(9,0) NOT NULL, 

DEPTCODE CHAR(3) NOT NULL, 

CLASSNUM DECIMAL(3,0) NOT NULL, 

YEAR DECIMAL(4,0) NOT NULL, 

SEMESTER DECIMAL(1,0) NOT NULL, 

SECTION DECIMAL(2,0) NOT NULL, 

GRADE DECIMAL(2,1) NOT NULL WITH DEFAULT) 

CREATE UNIQUE INDEX SCHOOL.NRL 

ON SCHOOL.ENROLLMENT (STUDENT#, DEPTCODE, 

CLASSNUM, YEAR, SEMESTER, SECTION) 

CREATE TABLE SCHOOL.CNSELAPPT 

(STUDENT# DECIMAL(9,0) NOT NULL, 

YEAR DECIMAL(4,0) NOT NULL, 

SEMESTER DECIMAL(1,0) NOT NULL, 

GPA DECIMAL(4,3) NOT NULL, 

APPT_YR DECIMAL(2,0) NOT NULL WITH DEFAULT, 

APPT_MO DECIMAL(2,0) NOT NULL WITH DEFAULT, 

APPT_DY DECIMAL(2,0) NOT NULL WITH DEFAULT, 

APPT_CODE CHAR(1) NOT NULL) 

CREATE UNIQUE INDEX SCHOOL.CSL 

ON SCHOOL.CNSELAPPT (STUDENT#, YEAR, SEMESTER) 

CREATE VIEW SCHOOL.FACULTY 
AS SELECT * 

FROM SCHOOL.EMPLOYEE 
WHERE CATGEGORY = 'FACULTY' 

CREATE VIEW SCHOOL.COUNSELOR 
AS SELECT * 

FROM SCHOOL.EMPLOYEE 
WHERE CATGEGORY = 'COUNSELOR' 

Figure 9 Finding faltering students 

Finding Faltering Students 

C/EXEC SQL 

C+ DECLARE TROUBLE CURSOR FOR 

C+ SELECT STUDENT#, SUM(GRADE * CREDITS)/SUM(CREDITS) 

C+ FROM SCHOOL.ENROLLMENT, SCHOOL.CLASS 

C+ WHERE SCHOOL.ENROLLMENT.DEPTCODE = SCHOOL.CLASS.DEPTCODE 
C+ AND SCHOOL.ENROLLMENT.CLASSNUM = SCHOOL.CLASS.CLASSNUM 
C+ AND YEAR = :ACYEAR AND SEMESTER = :ACSEM 
C+ GROUP BY STUDENT# 

C+ HAVING MIN(GRADE) 1.0 OR MIN(GRADE) 

C+ SUM(GRADE * CREDITS)/SUM(CREDITS) - 1.0 
C/END-EXEC 
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If you are a newcomer to the "native" AS/400 world, you know that you will eventually have to 
become proficient with CL. Former System/36 programmers are usually astounded at the sheer 
volume of commands used in CL. After all, S/36 OCL and operator commands are condensed 
into one small handbook. 

But you don't have to learn everything in all five volumes of IBM's CL Reference to get started. 
In fact, you will discover that there are two broad classifications of CL commands: those that 
cause the system to perform some action, and those that are used as programming constructs. 
Included in the "programming constructs" category are such commands as IF, DO, CHGVAR, 
and so on. These commands cannot be used interactively, since they do not make any sense in 
that context. They are used in compiled CL programs. We will examine these kinds of 
commands this month. 

Using Variables 

Last month, you learned that every variable used in a CL program must be "declared" at the 
beginning of the program. Be sure to review last month's article if you are unclear about this. 

As usually happens with program variables, we need to manipulate, change and compare them. 

In some cases, you can perform the manipulations outside of the program, and pass the variables 
into the CL program in the format that you require. For example, you can use an RPG program to 
prepare a variable, then pass it using a PARM statement. Sometimes it is more convenient to 
pass the "raw" variables to the CL program and let it perform the manipulations. This is 
especially true with character string operations, since CL is somewhat easier to use than RPG. 

One of the simplest operations to perform on a variable is to equate it to another variable, or to a 
constant. Figure 1 shows an example of equating a variable to another variable or to a constant, 
using both RPG and CL. Notice that line3 of each example shows how to clear a variable. You'll 
soon learn how to clear just part of the variable, if that is what you want to do. 
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The important command here is the "CHGVAR" (Change Variable) command. There are two 
parameters to this command: the variable to change, and the value to change it to. 

Changing One To Another 

You can use the CHGVAR command to change a numeric variable to character, or vice-versa. 

This is similar to using the RPG "MOVE" opcode. The rules governing this type of usage are on 
page 2-18 of the CL Programmer's Guide (SC21-8077). Essentially, you have to be sure that you 
have enough "space" in the target variable to receive the new value. Also, pay attention to the 
rules for decimal point alignment. 

3 Kinds of CATs 

CL includes three useful concatenation operations, which, unfortunately, are not part of RPG. 

These operations are *CAT, *BCAT, and *TCAT (bobcat and tomcat?). You will find a 
complete write-up on these operations on page VI-142 of the Control Language Reference, 

Volume 1 (SC21-9775). To summarize the operations: 

*CAT joins two strings "as is" 

*BCAT joins two strings with one intervening blank (assuming there are no leading blanks in the 
second string) 

*TCAT joins two strings with no intervening blanks (assuming there are no leading blanks in the 
second string) 

I am not going to provide equivalent RPG examples, since it is too painful. It involves a lot of 
array processing. 

No Symbols, Please! 

In last month's article, I strongly recommended that you not use "symbols," but rather "letters" 
when you use these operations. Lor example, use the letters "*CAT", not the double bar (II). I 
first saw this problem many years ago on the System/38. We were using a 3262 printer that did 
not have the bar character as part of its symbol set. Looking at the listing, it took a long time to 
realize that something was missing. This is less of a problem now that laser and matrix printers 
are more commonly used. The problem now is trying to remember what the symbols themselves 
mean. If I am going to debug somebody's program and they have used symbols, I use SEU's scan 
and replace before doing anything else. 

Arithmetic? Of Course! 

CL can also be used to do simple arithmetic. The fundamental operations are supported: add (+), 
subtract (-), multiply (*) and divide (/). There is an obscure rule for the divide operator on page 
Vl-139 of the CL Reference, which says that a blank is required if the follows a variable 
name. System/38 programmers beware; I didn't recall this rule from the S/38, and when I looked 
it up, indeed it wasn't a S/38 rule. I assume it's based on the way the AS/400 uses the "/" for the 
delimiter in qualified names—so why couldn't they have used "\"? 

You can use the arithmetic operators with variables and constants to create simple or complex 
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expressions. If you are going to make a complicated formula, common sense should tell you to 
use parentheses to clarify the expression. I know, there is a hierarchy of operations, but why 
labor through that when you read the program? 

Some arithmetic examples are shown in Figure2. If you are going to use division, be aware that 
CL doesn't like "divide by zero" any more than the other languages. If you don't check for it, you 
can get a "MCH" type error message. You can do a couple of things about the divide-by-zero 
condition, as shown in Figure2. "Work around 1" shows how to ignore the error. In this case, the 
value of &BAD is unchanged. "Work around2" is used if you decide to assign a new value to 
&BAD if the division is invalid. "Work around3" ends up with the same result as "Work 
aroundl," in that the value of &BAD remains the same. The method you choose depends upon 
your requirements within the program. Just remember that if you don't use a work around, a 
message is going to end up somewhere. 

Getting a Piece of The Action 

There is another operation that you can use with character variables, the SUBSTRING function. 
This function can seem a bit tricky at first, since you can use it as either the VAR or the VALUE 
part of the CHGVAR command. In Figure3, examplel, the variable &STRING3 is being 
assigned a value. The value is the result of concatenating two pieces of the other variables. 
Example2 shows how to change part of a string. In this case, the value "overlays" the original 
string. 

The SUBSTRING function can become complicated, because you can use variables for both the 
starting position and length operands of the function. To further complicate things, the start and 
length operands can be expressions. The expression is evaluated first, then the value is used as 
the operand. I have mixed feelings about using expressions within the SUBSTRING function. If 
the expression is simple, for example, using only one operation, then I would probably use it 
within the function. When the expression is more complicated, I would rather evaluate the 
expression before the SUBSTRING function. By storing the evaluation in a temporary variable, I 
can then use that variable in the SUBSTRING function. The reason for doing the evaluation 
outside of the function is to make the program easier to understand. I sincerely doubt that there is 
any performance penalty with this technique. Maybe a few millionths of a second. Even so, I 
would rather keep each statement as clear as possible, rather than cram as much as possible into 
each statement, as in C-language. 

Arrays in CL 

Figure4 is an example of using a variable in the SUBSTRING function. In this example, the 
variable &START is used to indicate a variable starting position. This example shows how you 
can use CL to process a character string as an "array." In this case, the "array" is a character 
string of length 100, with each element ten characters long. To pick out each element, I use the 
SUBSTRING function. From the start position, I pick ten characters. By incrementing &START, 
I can move across the "array," picking out each element in turn. 

There is nothing special that you have to do to tell CL that you are using an "array." In RPG, you 
need to use an E-spec to define an array. In CL, the array is a "concept;" it is an array only 
because we treat it as such. This type of processing has a number of uses. For example, you 
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might have an RPG program that gets a list of files to process, then passes the list to CL as an 
array. The CL program breaks out each element as shown here. If you think of the alternative, of 
passing ten separate parameters, then processing each of the ten in the CL program, you will see 
why you want to become familiar with this type of construct. 

Making Choices... 

Another CL language element that can only be used in CL programs is the "IF" statement. 
Compared to the System/36 OCL equivalent, the CL IF is very powerful, allowing us to evaluate 
complex conditions. The CL IF also allows us to create almost incomprehensible conditions, so 
we will study some techniques that can be used to create complex, but understandable, IFs. 

The absolute bottomline of the IF is that the condition resolves to a value of "true" or "false," 
which is indicated in CL as "1" or "0". No matter how complicated the expression, you are going 
to end up with a "1" or "0", and your program will take action based upon that resolution. The 
reason why the condition can become so complicated is that CL lets us use *AND, *OR, and 
*NOT operators to create the condition. Without proper formatting and parentheses, the 
condition becomes very complicated. 

Figure5 shows several examples of IF conditions, ranging from the simple to the complex. 
Example A shows how to use an indicator in a CL IF statement. This example could be used 
with a prompt screen, where you equate Command3 with indicator03. The value of an "on" 
indicator is "1", so if the command key is pressed, the indicator is "1" and the statement is 
executed. You can code the condition as "&IN03*EQT", but that's not really necessary. When 
testing for a true of false (on or off) condition, the variable must be defined as type *LGL. 

ExampleB shows how to process a "not" condition. In this case, the value of &IN03 is evaluated 
first, then the value is changed to the opposite. So if &IN03 is "0", the statement is executed 
(take the "0", change it to "1", then evaluate the condition). 

In ExampleC, you see how to perform a comparison condition. Again, the evaluation resolves to 
a "1" or "0". When you compare a character string to a quoted literal, upper and lower case is 
significant. 

A compound, more complicated condition is shown in ExampleD. In this case, formatting and 
parentheses are used to help clarify the condition. The condition is really made up of an *OR 
test. An *OR evaluates to "1" if either of the conditions is true. The condition on the left is made 
up of an *AND test. With an *AND, both sides of the condition have to evaluate to "1" if the 
condition is to evaluate to "1". So, to understand this condition, start with the "innermost" 
conditions. First, evaluate the "&MBR*EQ&SAVMBR" condition. That will resolve to a "1" or 
"0". If it evaluates to "0", we're out of the *AND test, since it doesn't matter what the other side 
evaluates to. If it evaluates to "1", then we check the other side of the *AND, which in this case 
is the condition "&SAVE". Since "&SAVE" is not being compared with anything, we can 
surmise that &SAVE is a logical variable (*LGL), with a value of "1" or"0". By the way, I feel 
that if you are going to use a variable as a logical variable, you should declare it as such, instead 
of as a character variable of lengthl—just to help you keep things in focus. (Think of CL logical 
variables as "indicators," similar to RPG. Forget your nonsensical prejudices about "never using 
indicators." In some cases, logical variables are the most meaningful variable type to use. 
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Besides, you can declare the variable with a name up to ten characters long, so you can attach 
"significance" and "meaning" to the variable if you want.) 

So each side of the *AND resolves to "1" or "0". If we have two "l's", then we can forget the rest 
of the IF condition, since the *OR evaluates to "1" if either side is "1". However, if the *AND 
evaluated to "0", then we have to check the right side of the *OR. This is the same as in 
exampleC. 

I have never run into a limit, in terms of the number of conditions that I've checked in an IF 
statement. I would guess that the most complex condition I've used had a dozen tests within it. 
Usually, when I start getting more than four or five tests, I try to simplify the tests. You might 
find it easier to move some of the conditions out of the IF test. For example, look at Figure5, 
examplesD and E. In exampleE, I evaluate the condition &SAVE, then use it in exampleD. In a 
CL program, I would place exampleE immediately before exampleD. The condition is evaluated 
before the IF statement; once in the IF statement, I only have to concern myself with the " 1" or 
"0" value of &SAVE, not with the evaluation of the condition that sets &SAVE. If you find 
yourself creating a complex IF condition, and are not comfortable with the results, see if you can 
move some of it outside of the IF. And don't even think twice about any possible adverse effects 
upon performance. Your AS/400 is slow because of things like the amount of memory in the 
system, number of disk arms, and batch jobs running interactively, not because of trivial details 
like this. 

...and Carrying Them Out 

When you use an IF statement, it is because you either do or don't want to do something. The 
"something" that you want to do is generally in the "THEN" part of the IF statement. IF it is 
Monday, THEN I will go to work. The rule for the THEN statement is that it can be one 
command. In many cases, that's all you need, as in the "I will go to work" THEN. Sometimes, 
though, you will need to associate more than one statement with the THEN statement, for 
example, IF it is Monday, THEN I will take my kids to school, go to work, and go to the bank. 

You don't want to repeat the IF test for each of the result conditions. CL lets you group all of the 
results into "one" statement by using a DO group. This is a noniterative DO, and its only purpose 
is to allow you to group several statements together, considering them as one. For example, in 
Figure6,1 am creating an RPG program, then creating a copy of it in another library. This is all 
based upon the condition of "&ODOBAT*EQ'*RPG"'. In this case, the CRTRPGPGM, 
CRTDUPOBJ and MONMSG commands are allowed because I use the "DO" statement within 
the THEN. Note that I have to tell CL where the "DO" group ends, using the ENDDO statement. 

You can include other IF conditions within the DO group, if you need to. If you also use DO 
groups for those internal IF statements, then you will have to use terminating ENDDOs for each 
of the DO groups. As we discussed in last month's article, you should use SEU to indent these 
internal IF statements, so that you can match up the DO and ENDDO statements. 

The IF statement also lets you use an ELSE condition. Figure7, exampleA shows how: I will 
create either an RPG or a COBOL program, depending upon the value of &ODOBAT. The 
CMD part of the ELSE statement is limited to "one command," which the IF statement evaluates 
to. I could also have written this as shown in exampleB, where I am using a DO group as the 
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ELSE command. 


Finally, exampleC shows an alternative when you only need one statement: just code the 
statement, without a DO group. Most people seem to always code a DO group, regardless of the 
number of statements that are being used, and I seem to use each method about half the time. I 
guess the advantage of always using the DO group is that the group is already set up for you, if 
you modify the program and include more commands. Take your pick. 

Real Life 

We have covered a lot of material in this article. Now we will put it to use. In Figure 8, the 
example program (SAVESPLF), in addition to being useful in this article, may be useful in your 
shop. The program will copy all spool files for a selected job into a physical file. You can then 
save the physical file on a diskette or tape. This lets you keep a copy of your reports offline, and 
might be useful for audit or recovery purposes, or for those times when you need another copy of 
a report but can't rerun the program that produced it. 

Take a moment to look at the program. Notice that I have used the formatting rules that I 
discussed last month. There are good comments, the DCLs are aligned, keywords are used in all 
commands, and white space is used to group related commands. If you compare this listing with 
listings that don't follow the formatting rules, you'll see that this program is easier to follow. 
Although it may be a bit longer than other CL programs you have seen, there is an overall 
"relaxed" feeling to it. Little things really do add up and make a difference when you deal with 
programming style. 

Before dissecting the program, let's review what went into it. The CPYSPLF (Copy Spool File) 
command can be used to copy a spool file to a disk file. This is the equivalent of the S/36 
COPYPRT command. So I can get my reports to disk. The next problem is, how do I tell my CL 
program to work with a list of reports, copying each of the entries in the list? For example, I 
might want to save all of the reports for a payroll run, and there could be 20 or 30 reports. I 
certainly don't want to manually enter the CPYSPLF command for each report. 

I know that I can get a list of reports by using the WRKOUTQ (Work with Output Queue) 
command. The problem with this command is that it will only produce a list on the screen or on a 
printout. To get a list that my program can work with, I will have to direct this command's output 
to a spool file, then copy that spool file to a physical file. (Please remember this, since I will 
bring it up again at the end of this article.) 

Once I have my list in a form that the CL program can work with, I go through the list. Since the 
list shows all of the spool files in an output queue, I have to pick out just the spool files that I'm 
interested in. In this case, I decide to select spool files based upon the job name. This is an 
example of why you should use a meaningful job name on the SBMJOB (Submit Job) command 
JOB parameter, rather than accept the system default job name. If I find a spool file on the list 
that I want to save, I copy that spool file to a physical file member, in a file that I specify to 
receive the copies. 

That's the overview, now let's get specific. 

Getting Started 
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If you choose to key and compile the sample CL program, SAVESPLF, you must create a file in 
QTEMP called WORK132. Use the following command to do this: 

CRTPF FILE(QTEMPAVORK132) + RCDLENQ32) SIZE(*NOMAX) 

After the file is created, the CRTCLPGM command must be run in interactive mode in the same 
job that was used to create file WORK132. 

Lines 140 of the program are comments, the PGM statement and DCLs. The comments describe 
the purpose of the program and the purpose of each variable. The PGM statement has a label, 
which is the name of the program. The parameters needed in this program are also given on this 
statement. Later in this series, you will see some other ways to get parameters into a program, 
but for now, we're using the PARM options. Notice that the *CHAR variables are in a nicely 
formatted, alphabetized list. The sole *DEC variable follows the *CHAR list. Finally, I declare a 
work file in library QTEMP. If this program is submitted to batch, then the work file is 
automatically "deleted" when the program ends, since the batch job's QTEMP is destroyed. If the 
program is run interactively, then the file is deleted at sign off. 

The physical file that will contain the spool file copies is created in lines 4650. Note that the 
physical file I create is not "externally" defined. Instead, it is a sequential file with a record 
length of 136 (more about the record length soon.) Also notice that this physical file can contain 
any number of members up to the system maximum of 32,767. Each member can contain up to 
16,777,215 records. (Even *NOMAX has limits.) I don't want to add a member yet, so I specify 
*NONE for the MBR parameter. 

As the final part of the program initialization, I get the list of the spool files in our selected 
output queue. Lines 5665 are used for this purpose. In line 56,1 create the work file that will 
contain the spool file listing. This is created with a record length of 132, to accommodate the 
width of the printout that is copied into this file. 

To get the output queue listing, I decided to create a "unique" spool file name for the listing, so 
that I can manipulate it easily. One technique for creating "unique" names is shown in lines 59 
and 60. The RTVJOBA (Retrieve Job Attributes) command retrieves the six-character job 
number. The job number is assigned by the system, and is unique for every job in the system. 

That means that every batch job gets a unique number, and every time you sign on you get a new 
number. Since my unique name can't start with a number, I concatenate the string "WK" to the 
number, in line 60. 

The OVRPRTF (Override Printer File) command on line 62 tells the system that I want the file 
QPRTSPLQ to be put on HOLD when it reaches the output queue. I also want to use my unique 
name, instead of the name QPRTSPLQ. That way, I can pick out "my" file from any potential 
duplicates. I knew QPRTSPLQ was the file used by the WRKOUTQ command by referencing 
the "Files Used by CL Commands," in Appendix D of the CL Reference manual, Vol 1. The 
OVRPRTF takes effect when the program reaches line 63, and performs the WRKOUTQ 
command. The WRKOUTQ produces a printed listing for the selected output queue. Line 64, 
CPYSPLF, grabs the output queue list and copies it into my temporary work file, and line 65, 
DLTSPLF (Cancel Spool File), gets rid of the listing, since I no longer need it. 

Take a Breather 
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Stop and review the action up to this point. I now have a work file ready to receive copies of 
spool files. I specified the name of the work file by passing the file name and library as 
parameters to this program. By passing the name as a parameter, rather than hard-coding it, I can 
run this program many times in succession. Using different parameter values, I can create several 
physical files containing spool file copies, without having "collisions." 

I have also produced a list of spool files in a selected output queue. That list is in a physical file 
that the program can use, file QTEMPAVORK132.1 now want to read this file and pick out the 
spool files that I am interested in. 

How Did He Do That? 

One of the most annoying problems with CL is that there are many commands that produce the 
output that you want, but in an "unformatted" form. When you have to deal with one of these 
unformatted lists, you have to examine the list and figure out some way to determine the parts of 
the list that you need. 

At this point in the program, my output queue listing is in a physical file. I read a record from 
this file in line 72. The program "sees" this record as a character string of length 132. That's all it 
sees. If I dump this file to the printer, I can see the records that I want the program to be 
interested in, so I have to tell the program how to know when it should process a record. Lines 
75-77 are used to tell the program when it should process a record. 

When you want to use this type of construct, that is, when you are dealing with a command that 
only produces output to a spool file, you have to copy the spool file into a work file. You should 
then "dump" the work file to the printer, and examine it so that you can find an "identifier" for 
the records that you want to use. You've got to be careful and pick something that is unique to a 
certain position in the record. 

Line 75 is kind of a "record identifier," and is used the same as in RPGII when you pick a record 
identifying character on the I-spec. In this case, I figured that records containing the in 
position 114 are records that I want to check. There is no magic to the it just differentiates 
the "detail" records from the "header" records. 

The second part of this IF condition, on line 76, tests for the job name. Positions 8291 of the 
spool file record contain the job name associated with a spool file. The name must be the same as 
the job that I selected to copy. The third part of the IP condition, on line 77, tests for a page count 
of non-blank. (We want to ignore any open spool file that may have no pages.) If all three 
conditions are met, then I proceed with the DO group. Otherwise, I skip to the ENDDO on line 
129. The reason for checking for the job name is that the output queue might contain spool files 
for many different jobs. Since I am only interested in one particular job, I have to check for it. 

Piecing It Together 

Now that I have an "interesting" record, I can start making use of it. Pirst, I want to get the 
parameters needed to copy the spool file identified by this record. Those parameters are "split 
out" on lines 7881. Again, I determined the positions of the parameters by examining a dump of 
the work file. 
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Because I want to save each spool file into a separate member in the save physical file, I have to 
create a unique member name and add that member to my save file. I decided to create a unique 
member name by concatenating the first six characters of the spool file name with the spool 
number. Within each job that produces spooled output, the system assigns a unique spool number 
to each spool file. The number can be up to four digits long. In my work file, the spool number is 
"zero suppressed," so I add the zeros back into the spool number in lines 87-92. All I'm doing 
there is checking the first three positions of the &SPLNBR variable. If a position is blank, I put a 
zero in its place. 

On lines 100-101,1 create the member name. The first six characters of the spool file name and 
my (now) zero-filled spool file number. But there's another small problem: if the spool file name 
is less than six characters long, I'll have a blank space in the member name, &SAVEMBR. This 
won't fly when I use the ADDPFM (Add Physical File Member) command on line 117. So, I 
made a small loop to examine positions two through six of my member name. If any of those 
positions are blank, I stuff an underscore character in, to connect the spool file name with the 
spool number. 

To make my saved members really nice, and to help me find a member if I restore the saved file, 

I create a nice text description for the member on lines 114-116. This includes the original file 
name, the complete job identifier (job, number and user) and the spool file number. 

With a unique member name, and a fairly nice text description to go with it, I use the ADDPFM 
command on lines 117118 to add a member to my save file. 

All That For This? 

It is almost anticlimactic to finally copy the spool file to the save file. The CPYSPFF command 
on lines 125127 performs the actual work. All of the pieces of this command are either 
parameters to this program, or determined from processing within the program. 

The CTFCHAR parameter requires a bit more explanation, and will explain why I created my 
save file with a record length of 136 on line 48. If you look up the CPYSPFF command in CF 
Reference, Volume 3, page V3-44 (SC21-9777), you will find that you have a few choices for 
this parameter. This is used to tell the CPYSPFF command to add "control characters" to the 
records that make up the saved spool file. You use the control characters when you restore the 
saved spool file and reprint the report. Because I selected the *PRTCTF option, I will get an 
extra four characters appended to the front of each spool record. Assuming that the maximum 
width of my original reports is 132,1 need to create a record that is 136 characters long to 
contain the control characters plus my report record. If you are going to save reports that are 
wider, you will have to create a save file with longer record lengths. On the other hand, if you 
know that all of the reports are shorter, you can use the shorter length. Note that the record length 
used on the CRTPF command is the length for all of the members in the file, so even if you only 
have one report that is longer than the others, you have to accommodate that. If you are 
incredibly adventurous, you can use the WRKSPFFA (Work with Spool File Attributes) 
command, and actually determine the record length for an individual spool file. You could then 
save spool files to different save files, depending upon record length. This would be a nasty 
programming job, since WRKSPFFA is another command that requires output to a spool file, 
then CPYSPFF to a physical file to get at the information. 
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Finally, the program "loops" on line 131. The loop is back to the "RCVF" statement on line 72. 
At end-of-file, the program branches to the ENDPGM statement, and ends. 

What Did You Learn? 

The SAVESPLF program used practically all of the techniques presented in this article. It may 
take a while to assimilate all of these techniques. If any of this is unclear, go back to the specific 
part of the program and review the statements. If you keep in mind "what" has to be done, "how" 
it is being done should be easier to understand. As you start writing your own CL programs, you 
will find many instances where you can use these commands. 

Homework 

I have decided to give you some homework this month, so that you can get in on some of the fun. 
I selected these assignment because they tie in with this article and last month's article, and they 
will greatly add to your understanding and appreciation of CL. 

You should write a RSTSPLL (Restore Spool Lile) program to work with the SAVSEPLL 
program presented here. The RSTSPLL program should restore your save file, and process the 
selected member to produce a copy of the saved report. You will have to use a language other 
than CL to interpret the control characters, so that you will get the correct spacing on the report. 
Note that one of the options of the CTLCHAR parameter on the CPYSPLL command is 
"*S36LMT", so if you already have a S/36 program to work with COPYPRT files, you might be 
able to use that. 


As you've seen in this article, the character string capabilities of CL are better than in RPG. You 
should write a general purpose character-string processor in CL that you can call from RPG. 
Start thinking about getting away from the array processing that you use in RPG. You should 
create routines within the CL program to do the three types of concatenation, left and right 
justify, and center. 

Linally, look in Appendix D of CL Reference. This is a list of output files that you can use with 
AS/400 commands. Most of the commands provide output to a printer file, but precious few let 
you direct the output to a disk file, where you can more directly get at the information. (See 
Appendix D of the CL Reference manual, Vol 1.) This means that for any of the commands that 
supply only a printer file, you will have to use techniques similar to those shown in this article: 
produce a spool file, copy that to a work file, then try to figure out where the data is that you 
want. This is really an intolerable situation, and I had hoped that IBM would fix this from the 
System/38 to the AS/400. But they haven't. Consider writing a letter to Rochester, asking 
(telling?) them to add OUTLILE options to all of the DSP and WRK commands. 

Next month: several commands and concepts that you need to know to get maximum 
performance from your database. 


Figure 1 CHGVAR command 


In RPG: 

MOVELFLD1 FLD2 
MOVEL'WORK1' FLD2 
MOVEL*BLANKS FLD2 
In CL: 


CHGVAR Command 
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CHGVAR VAR(&FLD2) VALUE(&FLD1) 

CHGVAR VAR(&FLD2) VALUE('W0RK1') 

CHGVAR VAR(&FLD2) VALUE(' ') 

Figure 2 CL arithmetic 

Arithmetic 

CHGVAR VAR(&CIRCUM) VALUE(&DIAM * 3.1415) 

CHGVAR VAR(&GROSS ) VALUE(&RATE * &HOURS) 

Problems here: 

CHGVAR VAR(& ZERO) VALUE(0) 

CHGVAR VAR(&BAD ) VALUE(&BAD / &ZERO) 

Work around 1: 

CHGVAR VAR(&BAD) VALUE(&BAD / &ZERO) 

MONMSG MSGID(MCH1211) 

Work around 2: 

CHGVAR VAR(&BAD) VALUE(&BAD / &ZERO) 

MONMSG MSGID(MCH1211) EXEC(CHGVAR VAR(&BAD) VALUE(1)) 
Work around 3: 

IF COND(&ZERO *NE 0) THEN( + 

CHGVAR VAR(& BAD) VALUE(&BAD / &ZERO)) 

Figure 3 Substring and concatenation 

Substring and Concatenation 
DCL VAR(&STRING1) TYPE(*CHAR) LEN(ll) + 

VALUE('DATANETWORK') 

DCL VAR(&STRING2) TYPE(*CHAR) LEN(ll) + 

VALUE('AUGUST 1989') 

DCL VAR(&STRING3) TYPE(*CHAR) LEN(ll) 

Example 1: 

CHGVAR VAR(&STRING3) VALUE((%SST(&STRING1 14))+ 

*BCAT (%SST(&STRING2 84))) 

/* &STRING3 is now "DATA 1989" */ 

Example 2: 

CHGVAR VAR(%SST(&STRING1 1 7)) VALUE(%SST(&STRING2 1 7)) 
/* &STRING1 is now "AUGUST WORK" */ 


Figure 4 Using an array in CL 

Using an Array in CL 
DCL VAR(&ARRAY ) TYPE(*CHAR) LEN(IOO) 

DCL VAR(&ELEMENT) TYPE(*CHAR) LEN(10 ) 

DCL VAR(&START ) TYPE(*DEC ) LEN(3 0) VALUE(1) 
LOOP: CHGVAR VAR(&ELEMENT) + 

VALUE(%SST(&ARRAY &START 10)) 

IF COND(&ELEMENT *NE ' ') THEN(DO) 

...various CL commands here 
ENDDO 

CHGVAR VAR(&START) VALUE(&START + 10) 

IF COND(&START *LE 91) + 

THEN(GOTO CMDLBL(LOOP)) 


Figure 5 Various IF conditions 


Example A: 

Example B: 

Example C: 
Example D: 

Example E: 


Various IF Conditions 
DCL VAR(&IN03) TYPE(*LGL) 

IF COND(&IN03) THEN(RETURN) 

DCL VAR(&IN03) TYPE(*LGL) 

IF COND(*NOT &IN03) THEN(DO) 

IF COND(&ODOBAT *EQ '*RPG') THEN(DO) 

IF COND(((&MBR *EQ &SAVMBR) *AND (&SAVE))+ 
*OR (&SAVEALL *EQ '*YES')) THEN(DO) 
CHGVAR VAR(&SAVE) VALUE(&SAVEONE *EQ '1') 


Figure 6 Using DO for several statements 

IF COND(&ODOBAT *EQ '*RPG') THEN(DO) 

CRTRPGPGM PGM(&LIB/&ODOBNM) SRCFILE(&LIB/&SRCFILE) 

CRTDUPOBJ OBJ(&ODOBNM) FROMLIB(&LIB) OBJTYPE(*PGM) TOLIB(&TOLIB) 
MONMSG MSGID(CPF0000) 

ENDDO 
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Figure 7 Example of ELSE command 

Example A: 

IF COND(&ODOBAT *EQ '*RPG') THEN(DO) 

CRTRPGPGM PGM(&LIB/&ODOBNM) SRCFILE(&LIB/&SRCFILE) 

ENDDO 

ELSE CMD(IF COND(&ODOBAT *EQ '*CBL') THEN (DO)) 

CRTCBLPGM PGM(&LIB/&ODOBNM) SRCFILE(&LIB/&SRCFILE) 

ENDDO 
Example B: 

ELSE CMD(DO) 

IF COND(&ODOBAT *EQ '*CBL') THEN(DO) 

CRTCBLPGM PGM(&LIB/&ODOBNM) SRCFILE(&LIB/&SRCFILE) 

ENDDO 
ENDDO 
Example C: 

IF COND(&ODOBAT *EQ '*RPG') THEN( + 

CRTRPGPGM PGM(&LIB/&ODOBNM) SRCFILE(&LIB/&SRCFILE)) 

Figure 8 Example program to copy spool files to a physical 

SAVESPLF: + 

PGM PARM(&JOB &OUTQ &OUTQLIB &SAVEFILE &SAVELIB) 


DCL 

VAR(& FILENAME) 

TYPE i 

(*CHAR) 

LEN(10) 

DCL 

VAR(&JOB) 

TYPE i 

(*CHAR) 

LEN(10) 

DCL 

VAR(&JOBNBR) 

TYPE i 

(*CHAR) 

LEN(6) 

DCL 

VAR(&MBRTEXT) 

TYPE i 

(*CHAR) 

LEN(50) 

DCL 

VAR(&NUMBER) 

TYPE i 

(*CHAR) 

LEN(6) 

DCL 

VAR(&OUTQ) 

TYPE i 

(*CHAR) 

LEN(10) 

DCL 

VAR(&OUTQLIB) 

TYPE i 

(*CHAR) 

LEN(10) 

DCL 

VAR(& SAVEFILE) 

TYPE i 

(*CHAR) 

LEN(10) 

DCL 

VAR(&SAVELIB) 

TYPE i 

(*CHAR) 

LEN(10) 

DCL 

VAR(& SAVEMBR) 

TYPE i 

(*CHAR) 

LEN (10) 

DCL 

VAR(&SPLNBR) 

TYPE i 

(*CHAR) 

LEN(4) 

DCL 

VAR(&USER) 

TYPE i 

(*CHAR) 

LEN(10) 

DCL 

VAR(&WORKNAME) 

TYPE i 

(*CHAR) 

LEN(8) 

DCL 

VAR(&N) 

TYPE i 

(*DEC) 

LEN(1 0) 


DCLF FILE(QTEMP/WORK132) 

/* Create file to save spool files */ 

DLTF FILE(&SAVELIB/&SAVEFILE) 

MONMSG MSGID(CPF0000) 

CRTPF FILE(&SAVELIB/&SAVEFILE) RCDLEN(136) MBR(*NONE) + 

MAXMBRS(*NOMAX) SIZE(*NOMAX) 

MONMSG MSGID(CPF0000) 

/* Get list of spool files in specified OUTQ, put list in work + 
file */ 

CRTPF FILE(QTEMP/WORK132) RCDLEN(132) SIZE(*NOMAX) 

MONMSG MSGID(CPF0000) 

RTVJOBA NBR(&JOBNBR) 

CHGVAR VAR(&WORKNAME) VALUE('WK' *CAT &JOBNBR) 

OVRPRTF FILE(QPRTSPLQ) HOLD(*YES) SPLFNAME(&WORKNAME) 

WRKOUTQ OUTQ(&OUTQLIB/&OUTQ) OUTPUT(*PRINT) 

CPYSPLF FILE(&WORKNAME) TOFILE(QTEMP/WORK132) 

DLTSPLF FILE(&WORKNAME) 

/* Read list of spool files. If spool file entry is for job to + 
be saved, copy spool file to save file */ 

TAG05: + 

RCVF 

MONMSG MSGID(CPF0000) EXEC(GOTO CMDLBL(TAG15)) 

IF COND((%SST(&WORK132 114 1) *EQ ' :') *AND (%SST(&WORK132 82 + 
10) *EQ &JOB) *AND (%SST(&WORK132 46 1) *NE ' ')) THEN(DO) 

CHGVAR VAR(&FILENAME) VALUE(%SST(&WORK132 2 10)) 

CHGVAR VAR(&USER) VALUE(%SST(&WORK132 13 10)) 

CHGVAR VAR(&SPLNBR) VALUE(%SST(&WORK132 73 4)) 

CHGVAR VAR(&NUMBER) VALUE(%SST(&WORK132 93 10)) 

/* "Zero fill" spool number */ 

IF COND(%SST(&SPLNBR 1 1) *EQ ' ') THEN(CHGVAR + 

VAR(%SST(&SPLNBR 1 1)) VALUE('0')) 

IF COND(%SST(&SPLNBR 2 1) *EQ ' ') THEN(CHGVAR + 

VAR(%SST(&SPLNBR 2 1)) VALUE('0')) 

IF COND(%SST(&SPLNBR 3 1) *EQ ' ') THEN(CHGVAR + 

VAR(%SST(&SPLNBR 3 1)) VALUE('0')) 

/* Create name of save member. This is first 6 characters of + 
filename concatenated with spool number. If there are any + 
blanks in positions 2-6, fill blanks with underscore + 
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char. */ 

CHGVAR VAR(&SAVEMBR) VALUE(%SST(&FILENAME 1 6) *CAT &SPLNBR) 
CHGVAR VAR(& N) VALUE(2) 

TAG10: + 

IF COND(%SST(&SAVEMBR &N 1) *EQ ' ') THEN(CHGVAR + 

VAR(%SST(&SAVEMBR &N 1)) VALUE('_')) 

CHGVAR VAR(&N) VALUE(&N + 1) 

IF COND(&N *LE 6) THEN(GOTO CMDLBL(TAG10)) 

/* Create text for saved member, add save member to save file */ 
CHGVAR VAR(&MBRTEXT) VALUE('File:' *BCAT &FILENAME *BCAT &JOB + 
*TCAT '/' *CAT &NUMBER *CAT '/' *CAT &USER *BCAT &SPLNBR) 
ADDPFM FILE(&SAVELIB/&SAVEFILE) MBR(&SAVEMBR) TEXT(&MBRTEXT) 
MONMSG MSGID(CPF0000) 

/* Copy spool file to save member */ 

CPYSPLF FILE(&FILENAME) TOFILE(&SAVELIB/&SAVEFILE) + 

JOB(&NUMBER/&USER/&JOB) SPLNBR(&SPLNBR) TOMBR(&SAVEMBR) + 
CTLCHAR(*PRTCTL) 

MONMSG MSGID(CPF0000) 

ENDDO 

GOTO CMDLBL(TAG05) 

TAG15: + 

ENDPGM 
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When you process a member of a file, other than the first member, you must first issue the 
Override Database File (OVRDBF) command to "pick" the member. But how do you do this 
from within an RPG program if you don't know the name of the member before the program is 
loaded? For example, your RPG program accepts up to six source member names and then prints 
each of the members. 

You must issue OVRDBF for each member from within the program. The best way to do this is 
by calling QCMDEXEC. (A complete description of running QCMDEXEC from an RPG 
program can be found in "TechTalk," DataNetwork, August 1989.) 

Figure 1 shows partial code that illustrates the technique. You must declare the file as user 
controlled (UC in cols. 71-72) so it can be opened and closed explicitly. When you want to issue 
the OVRDBF, close the file, CALL QCMDEXEC, pass the OVRDBF string in parm 1 and the 
length of the string in parm 2, and then re-open the file. That's all there is to it. 

This same technique could be used to override program-defined logical file names with physical 
files. For instance, in the stated example, you might need to print members from several possible 
source physical files. The source physical file could be logically defined as SRCPF in the F-spec, 
but overridden as QRPGSRC, QDDSSRC, etc. 

DataNetwork staff 

Figure 1 OVRDBF from within RPG 

OVRDBF from Within RPG 

1... + . ..10....+...20..30....+...40 + ...50.... + .. .60_+ ...70.... + ...8 

FSRCOF IF F 92 DISK UC 

E ART 1 41 1 

C DO 6 X 

C MOVEAARM,X ART,32 

C CLOSE QRPGSRC 

C Z-ADD41 QLNG 155 

C MOVEAART,1 QTXT 41 

C CALL 'QCMDEXC' 
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QTXT 

QLNG 


c 

c 

c 

c 

* -k 

PARM QTXT 

PARM QLNG 

OPEN QRPGSRC 

END 

OVRDBF 

QRPGSRC *CURLIB/QRPGSRC 


Next 


Home 


Previous 









MIDRANGE 

COMPUTING 

HR PUBLICATIONS INC. 


TechTalk: Update on UPDDTA 
September, 1989 

Copyright 1989, Midrange Computing 


by Craig Pelkie 

A recent tip (DataNetwork, July 89) suggested using the UPDDTA command to quickly generate 
DFU programs for files. You can bypass the start-up time involved with each use by saving and 
reusing the generated program: 

1) Use the SETATNPGM command to set the attention key program to QCMD. 

2) Run UPDDTA for the file. 

3) As soon as you get into the DFU, press the ATTN key. 

4) Display QTEMP library. There will be a program and display file with names beginning with 
a "Q" (like QDZTD00001). Do a CRTDUPOBJ for the file and the program, duplicating and 
renaming them into a library of your choice. The name of the program and the display file must 
be the same. 

5) In the future, use the CHGDTA command, substituting the name of the program from step 4. 
Craig Pelkie San Mateo, CA 
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One of the common uses for subfiles is to display fields from multiple records, and then allow 
selection on any of the records for a complete display of the selected record's information. After 
viewing the detail information, a return to the multiple record display is usually desirable. 
However, how do you get the subfile display to begin with the same page of records that was 
displayed before? 

This is really quite simple by using the SFLRCDNBR keyword in the DDS specs of the subfile 
control record format. Here's how to use it: 

1) Set up a 4 digit zoned decimal field with zero decimal positions, data type of signed-numeric 
('S'in position 35), and the keyword entry SFLRCDNBR (starting in position 45) in the DDS 
subfile control record format. Make the field hidden ('H' in position 38) unless you have a need 
to display the first subfile record's record number. The SFLRCDNBR keyword is what indicates 
to your program the record number with which to begin the subfile display. 

2) Define the File Information Data Structure in the F-spec for the workstation file, and define a 
binary input field for the data structure using positions 378-379. (For more information on the 
File Information Data Structure, see "A Map to INFDS Positional Field Information," 
DataNetwork, March 1989). These positions will contain the subfile record number of the first 
subfile record displayed on the current page. 

3) Before overlaying the subfile display with another display, save the value of the field you 
defined in step 2. When it is time to re-display the subfile, just move the saved value into the 
DDS field you defined in step 1. The same subfile page that was displayed before will appear 
when you write the subfile control record. 

DataNetwork staff 
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Selected from DataNetwork's electronic bulleting board 
From: Jim Lacson To: ALL 

When chaining to an externally described file with a key consisting of multiple fields, I get the 
following message during compilation: "Factor 1 length not the same as first key field.." It seems 
that the compiler only recognizes one field as the key. Anyone have any ideas? 

From: Craig Pelkie To: Jim Lacson 

I'll give you an example, see if it helps, or let me know where it's unclear. Assume your external 
file is l ik e this: 

R EXTFILE 
FIELD1 
FIELD2 
FIELD3 
FIELD4 
K FIELD1 
K FIELD4 
K FIELD3 

That is, four fields, the first three alpha, and the last numeric, with a slightly "scrambled" key. 

In your RPG program, you can get at the complete key like this: 

$KEY1 KLIST 

KFLD KF1 10 

KFLD KF2 50 

KFLD KF3 8 

You have to use a KLIST, you can't use a data structure with three fields for the key to the 
external file. On the KLIST, the fields have to correspond in terms of length and attribute 
(alpha/numeric) with the key fields in the file. 

If you just need to chain with the first key field, you can chain without using the KLIST. You 
can use just a regular old variable, as long as it's defined as alpha, 10 characters (in this 


10A 
5A 
8A 
5 0 
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example). 


Just make sure your "program key fields" match up with the "file key fields," lengthwise and 
attribute wise. 

From: Jim Lacson To: Craig Pelkie 

In your example, you redefined the key fields in your source. Is there an advantage to doing this 
as opposed to using the externally described field name? Secondly, do I only have to do this once 
(i.e. in a one-time subroutine) as opposed to every cycle? Anyway, I finally got the time to get 
away and take an RPG/400 course in San Francisco next week. I'm sure I'll pick up on a lot of 
native stuff. 

From: Craig Pelkie To: Jim Lacson 

There is no reason why you couldn't use the external field names in the KLIST fields. I tend to 
use "different" field names, just to keep things straight (for me, at least). That is, a KFLD is a 
different field than a file field. Every time you want to use the KLIST to 
CHAIN/SETLL/READE on a file, you have to move values into the KFLDS, if you want to use 
different values. If you only need to chain to the file once, you can just move the KFLDS the 
first time in. It doesn't matter where in the source you define the KLIST. This is considered a 
"nonexecutable" statement, in that it really only serves to define the key fields. Kind of like a 
data structure, but used for a different purpose. Is it starting to make sense? 
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Selected from DataNetwork's electronic bulleting board 
From: David Rain To: ALL 

Hello all. I am planning to hookup a S/36 D2k to an AS/400 B30. They will be located in the 
same room. I have many questions. First, how fast can I connect the two machines. The S/36 has 
ELCA with 3 comm ports installed (RS232). I think I need a modem eliminator. Can I run it at 
56K. Next, what do I need to do to install DDM on both machines? Any pitfalls to be avoided? 
Finally, Passthru. I know that you can signon to the remote system and run application on the 
remote system. Can that remote application print on your local printer? How? 

From: Rich Loeber To: David Rain 

You can connect the two machines, but not at 56KB. The S/36 can only run 56KB over a DDSA 
connector and the S/36 DDSA connector is not compatible with the AS/400. We use modem 
eliminators running at 19.2 and the response time is adequate. 

To run DDM, you will need to order the DDM SSP support from IBM. On your D2K this is 
feature 6037 and costs $2,500! DDM support is included in OS/400. 

Passthru is for display stations only. There is a feature of ODF (Object Distribution Facility) that 
allows spool files to be transferred between AS/400s in a network. ODF is included in OS/400. 

ODF is an option on the S/36. I'm not sure of the cost or feature codes for the S/36. There are 
also several good third party products available that will handle printer pass-thru between S/36 
and AS/400. 

From: David Rain To: Rich Loeber 

Are you sure that there is no way to run at 56K? We plan on having large volumes of data 
transfer between the two machines. Typical files are 300,000 records long. Also, could you name 
some of the good third party people who have spool file transfer software. We need this to be as 
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transparent to users as possible. We are just emerging from the dark ages in data processing, and 
users are easily overwhelmed. 

From: Marl Allen To: David Rain 

Try Kisco Information Systems. They have a package for remote spool file and other file 
transfer/job execution. I think its called RBC/36 (advertises in DataNetwork). 

From: David Redlawsk To: David Rain 

Well, your other alternative is to attach the two machines via a token ring - that will go at 4MB. 
But it is expensive, and requires an old AT to attach the S/36. The AS/400 has an integrated 
token ring attachment available. It will probably cost you as much as $10K for all the hardware 
and software. But it will go fast! 
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Selected from DataNetwork's electronic bulleting board 
From: Ken Chaisson To: ALL 

I am trying to utilize the QUSRTOOL library that came with our AS/400. One of the tools is a 
program that will check a date to make sure that it is valid. I think it is called CHKDAT. Does 
anyone know how to work with this? I would appreciate it if anyone out there who has 
experience with this could help me. For instance, what is the code I need in my RPG/400 
program? Do I need to pass parameters or ...? What is the code? Do I need to write a CL program 
to pass these parameters to? Or ...? Thank you for any and all help! 

From: Craig Pelkie To: Ken Chaisson 

This command is described in QUSRTOOL/QATTINFO, member CHKDAT, which I suppose 
you've read by now. It appears that you will need to write a small CL program if you want to use 
this from RPG. For example, in RPG the program could look like the one in Figure 1. The CL 
program might look like the code in Figure 2. 

The trick seems to be with the "MONMSG", which indicates that the date is invalid. If you want 
to use some of the other options with this command, then you need to pass them as PARMs in 
RPG, and declare them in the CL program. You might try this, and see if it gets what you want. 

From: Ken Chaisson To: ALL 

Just a footnote concerning my question about QUSRTOOL library: I tried to ask, thru the Q & A 
database, the same question. Guess what? They answered back that they don't support questions 
concerning that library! Thanks a lot, IBM! 
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Selected from DataNetwork's electronic bulleting board 
From: Joe Grey To: ALL 

I have a client converting from a S/36 D2L, which is slower than molasses, to an AS/400 B50 
with 40 MB memory and 4.2 GB disk with 40-50 terminals. Software includes financials and 
fund raising, initially in S/36 environment. Will performance be noticeably affected by up to 15 
OFFICE users? IBM says no problem! Are there any users with this much activity out there? 

From: Dave Weston To: Joe Grey 

I am currently on a B 20 with ONE OFFICE user. Performance is dramatically affected whenever 
that one user signs on to OFFICE. I recently attended Mel Beckman's S/36 to AS/400 conversion 
seminar where he said for EVERY office user you need 800K of RAM. That's per user! Sweet 
dreams if you have 15! Maybe it's time for you to get a LAN with PCs or MACs. I've written 
articles about the efficiencies of that. 15 users on a LAN is a breeze. 15 on AS/400 OFFICE is, in 
my view, a nightmare. 
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Selected from DataNetwork's electronic bulleting board 
From: Tim Johnston To: ALL 

I have been having a problem with IBM'S 5250 Emulation Router. Whenever I call it up for any 
reason, the memory that it took is not given back to me until a reboot is performed. This gets old 
day after day. Has anyone else had the same problem? Does anyone have a solution? My SE says 
that this is just the way it is. I hope someone can prove him wrong. Any info would be 
appreciated. 

From: Terry Collins To: Tim Johnston 

Buy a PC utility called PopDrop. It will clear the memory for you. It is available all over, but if 
you need a place that carries it, try "Power Up" catalog. Their number is 1-800-851-2917. The 
price is $49.95. 

From: Mark Shooter To: Tim Johnston 

There is a set of Shareware programs, MARK, RELEASE, MAPMEM, and others. MARK 
places a small mark TSR in memory, RELEASE will look for the MARK and release all 
memory, including the mark. I use it on my 286 all the time, sometimes the PC/XT at work 
hangs. Check a local BBS. 

From: Larry Nottingham To: Terry Collins 

I saw your message to Tim Johnston and I purchased PopDrop. But I seem to be having a 
problem, in order for everything to work I must first drop all TSRs, then drop emulation by 
doing a CTL/ALT/DEL at the sign on, and then do a clear. Otherwise, if I just do a clear, my PC 
hangs. Is this the way you have to do it? 

From: Terry Collins To: Larry Nottingham 
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I do not have PCs attached to my S/36 twinaxially (all of mine are attached via token-ring), so I 
cannot help you with the specifics of using PopDrop in your environment. 

From: Norm Neil To: Tim Johnston 

You probably already know this but here goes anyway. You can regain some memory by 
canceling the router by doing a CTL/ALT/DEL function on the S/36 side. It will then take you 
over to the PC side and emulation will not be active. I had the same problem with memory and 
this worked for some of my applications. For others, it did not regain enough memory. I then 
installed an emulator board manufactured by CLI. Now, by doing the CTL/ALT/DEL function 
on the S/36 side, I seem to regain all my memory back. Hope this helps. 

From: Larry Nottingham To: Tim Johnston 

After you do the CTL/ALT/DEL at S/36 sign on, you can execute popdrop and all memory will 
be free. 

From: Mark Allen To: Norm Neil 

Most non-IBM emulation boards I have used WILL reclaim memory with an CTL/ALT/DEL. 
IBM emulation boards will not and IBM emulation also seems to hang most TSR utility 
programs that are supposed to reclaim memory. 
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As we rest up and resharpen our machetes a bit, you can see that the field of database 
management is large and thickly grown with roots, branches and vines. Even the Valley of the 
AS/400 DBMS is a sizable piece of real estate. Rather than try to clear it all for planting, we 
have been concentrating on cutting paths through the critical parts. Even though much remains to 
be said on the topic, then, after a couple of solid months of whacking away in the dense 
undergrowth of relational database interfaces, we must, as the travelogues used to say, bid this 
territory a fond farewell. 

New Code, New Words 

You have seen, over past months, that the relational idea of whole-file-at-a-time data access and 
manipulation operations is something genuinely different from what most of us have been 
accustomed to using in the programs we have built. Embedded SQL code, and the syntactic 
extensions defined to allow it to communicate with program code of the more traditional kind is 
unfamiliar to the eye and ear. It bears much the same relationship to the computer languages for 
which it is supported as an add-on, as do newly coined or borrowed vocabulary words in natural 
languages such as English. 

In fact the analogy is most precisely to words drafted into English from some foreign language 
because the concept embodied is not one that has any comparably concise English equivalent. 
Examples that come to mind include chutzpah and laissez faire. 

As we saw in last month's examples, SQL code can come in rather sizable chunks. But 
conciseness is a matter of relative magnitudes. Complex SQL queries may run to dozens of lines, 
but attempting to create the same result with conventional programming statements would put 
your line count into the stratosphere. 

Old Code, Old Words 

Of course conventional programming languages were not just sitting around waiting for SQL to 
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come along in order to manipulate externally filed data. Any RPG programmer knows what 
CHAIN and READ do. Other so-called "third generation languages," such as COBOL or PL/I, 
have equivalent record-oriented I/O operations defined. 

But virtually all of us started out in the computing profession at some point after the mid-1950s, 
when compiled languages were first implemented. We tend to think of CHAIN, READ and their 
relatives as being simple, "primitive" operations. Embedded SQL statements strike us as "fancy" 
or "high-level;" pieces of code that have a lot going on inside them. 

We forget, because we were not yet in this business — or maybe even born — at the time, but 
operations such as CHAIN or READ that could be coded in a line or two were looked upon as 
very high-level and cutting-edge when they first became available to the general run of 
programmer. Those crew cut coders of the 50s were fully as justified in their opinions of READ 
and its relatives as we are today in our points of view about SQL. 

Idioms 

In a natural language such as English, any figure of speech - usually some short, colorful, pithy 
expression — takes on the trappings of a compound word. An idiomatic expression is built from 
multiple words, but, just like a word, you tend to use them as whole units. You might say, for 
example, "getting down to brass tacks," but you would be quite unlikely to say, "getting to brass 
tacks," "getting down to brass," or "getting down to tacks." The expression has a meaning as a 
whole, but not as mix-or-match parts. 

Programming languages share with natural languages the tendency to develop idioms. This is 
particularly true of very low-level computer languages; so-called assembly languages. Most of 
the time, the basic unit of coding in an assembly language is a symbolic notation for a single 
hardware machine instruction. 

Programs that perform a function logically equivalent to a single line of code in a compiler-level, 
third-generation computer language tend to require anywhere from a few dozen to many 
hundreds of lines of assembly language code to implement. 

BIG READ 

It didn't take the early assembly language coders long to realize that a number of basic data 
manipulation chores kept cropping up repeatedly when they designed their programs. Doing 
record EO to and from the peripheral devices of the day constituted the largest class of 
commonly encountered large coding problems; large in the sense of needing a large number of 
assembly language code lines to express. 

At a minimum, assembly language programmers had to reserve space for record buffers and 
work areas, write code to establish current position pointers into any buffers that could hold more 
than one record, and also manage the transfer of record images between the buffer(s) and record 
work areas that were to be accessed by the rest of their program's logic. 

Artistic Bent 

Programming is, of course, a creative and interesting line of work, but only, by and large, to the 
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extent that you get to do new things at frequent intervals. Any worker at any job gets bored 
quickly if most of the work consists of paint-by-the-numbers repetition. 

A friend of ours who did experimental machining once remarked to us that, "I love making the 
first one of something. But if I've got a project that calls for, say, six identical pieces, doing the 
last five is just something I have to get through to get the whole thing done. The fun one is the 
first one." Virtually every programmer we have ever met would second this sentiment 
wholeheartedly. Small wonder, then, that assembly language programmers who figured out good 
ways to handle buffered record I/O were less than thrilled at the prospect of spending much of 
their time copying, with minor variations, their solutions into each new program like some crew 
of medieval monks. 

Factoring 

A mathematical equation can often be decomposed into a number of simpler factors that, in 
combination, are equivalent to the source equation when multiplied together. Assembly language 
programmers quickly reached the point of searching for a factoring-like solution to their own 
repetition problem. 

Making generalized subroutines out of good, debugged code is one way to attack the problem of 
needing to duplicate stereotypical code segments. But in an assembly-level computer language, 
even setting up to call a generalized I/O subroutine may involve your needing to write quite a lot 
of setup and check-for-errors-afterward pieces of code. 

In an era in which the typical source code storage medium was 80-column paper cards and card 
readers were neither fast nor accurate, there was an obvious incentive to invent ways of 
compressing the volume of source code to something less bulky than assembly language. 

Up Paradigm 

Even better than "containerizing" assembly language program code in callable subroutines, the 
idea of higher-level syntaxes and compilation soon cropped up. The statement types in these new 
languages were, in essence, parameterizable versions of the "idioms" that had first cropped up in 
assembly language programs. 

On Up 

We, as programmers, have now had over three decades of experience with compilable, general 
purpose programming languages. One of the things we have found, not too surprisingly, is that 
idiomatic expressions do not quit popping up just because you switch to writing your application 
code in a language derived from the idioms of its predecessor. In short, modem, high-level 
languages have their idioms too. And, just as the languages these new idioms crop up in are 
conceptually higher on the "evolutionary tree" than the languages that preceded them, so are the 
idioms. 

Take, for example, the commonly required chore of pulling in some kind of header record from 
one file and zero, one or more detail records from a second file. You could be dealing with an 
invoice and its detail lines, an order and its detail lines, an inventory report for a given 
warehouse and its detail lines showing goods on hand, etc. The "idiom" of the header and 
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variable numbers of trailer records is very commonly encountered in data processing system 
design. 

Idiomatic Implementation — SQL 

In SQL, you can specify this idiomatic data fetching exercise by calling for a join of the header 
file and the detail file on a field that each contains and whose values are drawn from a common 
domain of possibilities. For an invoice, this would be the invoice number; for an order, the order 
number; for an inventory report, the warehouse number or product class code. 

Idiomatic Implementation — Batch 

In conventional batch programming practice, you, as an RPG programmer would write a 
classical match/merge program with the header file as primary and the detail file as secondary. 
RPG is a good language in which to do such code because it has a number of features — 
explicitly designatable match fields, match indicators, record identification code specifications of 
a fill-in-the-blanks ki nd — that, themselves, constitute a box of "idiom helper" when you need to 
whip up such a standard dish. 

Idiomatic Implementation — On-line 

If your task is, instead, to produce such logic in an interactive form, you would probably write 
your program to first CHAIN (read record randomly by key) to the header file for a single, 
designated header record. Next, you would use SETLL, the set lower limits operation, to 
establish a position at the first record in the detail file with an invoice, order, warehouse, etc. 
number that matches that of the header. From this beachhead position in the detail file, you 
would then enter an input-and-compare loop using READ (read next record) and/or READP 
(read previous record) to get all the detail records that are associated with the current header 
record. 

Beads On A String 

Just as you can regard a READ or CHAIN statement as a lower-level language idiom that has 
been "kicked upstairs" by being made a primitive operation in a higher-level language, the 
AS/400s built-in DBMS has at least one feature that can be looked on as a still higher-level 
primitive derived from exactly this header and trailers idiom we have been examining. 

This feature is called the multiple format logical file (MFLF). From earlier installments in this 
series, you already know that a logical file in an AS/400 database has no actual records of its 
own. Rather, it is implemented as an alternate index on the records owned by a physical file. An 
MFLF is a special type of logical file whose access path (index) is established across the records 
of two or more physical files, all of which have some field or collection of fields in common. To 
a considerable degree, you can look at an MFLF as an approximately pre-sorted, pre-merged 
stream of records that can just be read up in order of indexation. You still have to write loop and 
compare logic in your program, but you can avoid most worries about sorting, merging or using 
lower limits logic. All of these are trickier to write than a simple read-and-compare loop. 

Idioms Of A Higher Kind 
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Thus far we have been considering idiomatic expressions in programming languages that consist 
of stereotyped sequences of a few particular statement types and/or the code segments that open 
and close a processing loop of some kind. But whole programs, even in high-level languages 
such as RPG, can often be looked upon as idioms of a sort themselves. 

File update programs that touch one header file record at a time; file update programs that touch 
one or more detail file records at a time and need read-only access to one or more master files; 
reports with columnar data and straightforward subtotaling: All of these are types of programs 
we have all written many specific examples of if our data processing careers have been lived in 
the mainstream of IBM midrange practice. 

Genres 

An entire program that is, in essence, just one big idiomatic expression, nonetheless differs from 
simpler idioms in important ways. One is the degree of parameterization needed to specifically 
define any one program of a given type instead of some other one of the near-infinite "cousin" 
programs it could be instead. There is, you should readily agree, a certain conceptual distance 
between an idiom like read-header-and-all-detail that can be parameterized by the names of the 
two files and the value of the header key for which the corresponding records are wanted, and, 
say, a general purpose file update or report writer utility. 

The difference between these classes of stereotypes is exactly the same as the difference between 
a simple idiomatic English expression such as "at the end of his rope" and an entire book that 
falls into one or another of the literary genres. Saying a particular program is a master file update 
program is the same, in terms of the high-level programming language used, as saying that a 
particular book in English is a romance, a techno-thriller, a spy story, a mystery, or a work of 
science fiction. 

Genre Boosters 

High-level software that is oriented toward cutting the effort required to produce entire "genre 
programs" has been around, in various forms, for quite a while. The System/36s Data File Utility 
(DFU) is one comparatively humble example of such a tool. 

Lately, both the number of genres addressed and the richness with which they are treated have 
taken large upward leaps. If you have followed the news — and also the advertising — in 
midrange periodicals over the past two or three years, it should be no secret to you that a number 
of vendors have introduced products that, using some form of very generalized, high-level 
specification, can then generate all or most of the RPG source code for programs or even entire 
application systems. 

Future of Idioms and Genres 

Such new tools seem to strike a lot of practicing programmers as simultaneously thrilling and 
scary. The same was true 30 years ago when compilable languages were displacing assembly 
languages as the principle programming tools in the typical data processing shop. The loss of 
flexibility and choices is one commonly expressed concern. 

There is some justice to this complaint with respect to some of the products now on the market. 
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But others have been designed to be as general as any of the popular compilable languages, yet 
without a comparable level of coding complexity. The market will tend to reward the latter and 
ki ll off the former over time. 

As for scary, well, speaking for ourselves — but, we suspect, also for a lot of others — we share 
the point of view of our friend the experimental machinist. We like doing the inventive stuff, not 
slogging through all the hand-coded details of a program that is not appreciably different than the 
one we wrote yesterday. 

Face facts. There is no upside potential in being a glorified copyist. If we do it right, that is no 
more than anyone would expect. If we slip up and introduce an error in the transcription and 
adaptation process, we lose points with our users and our superiors. Who needs that kind of grief 
if there is any possible way to automate the details so that they always work? 

Future Of Compilable Languages 

Even with high-level, specificational tools, however, compilable languages are not going away. 
First, not everyone is going to embrace new, higher-level technologies at the same rate. Second, 
there is a lot of existing code out there that will have to be maintained and improved in its 
"native tongue" until the day the high-level tool people create automated retrofitters that can 
translate and schlepp all that old code into their generator products. This is a very nasty general 
problem, so don't hold your breath. 

Short Of Nirvana, But Still Nice To Have 

So, familiar compilable languages will be with us for some time. The future, then, like the past, 
should see improvements to the languages. An example of an RPG improvement that was sorely 
needed when it arrived was the READP operation. Why shouldn't you be able to read backward 
as easily as forward, anyway? 

On The Square 

Computer scientists use the word "orthogonal" to describe a software system that allows you to 
do all related operations in essentially the same way and with a symmetrical set of options. File 
accessing in RPG was wildly non-orthogonal for a long time. The only ways to read backward in 
an RPG sequential file used to be to do all input with CHAIN by relative record number, or to 
doubly define the file, then use READ to go forward and CHAIN by relative record number to 
go backward. There was no good way, within the confines of the pre-READP RPG language 
itself to fake up a READP operation when your access to the file was via an index. 

The Cobbler Doesn't Wear His Own Boots 

As an editorial aside, it is worth noting that a lot of languages and other application tools have 
suffered from non-orthogonality over the years. The old IBM 5280 data entry computer had a 
dialect of RPG called DE/RPG that lacked a MOVEA (move array) operation. Needless to say, 
this made it virtually impossible to do anything very tricky with strings of text bytes or other data 
that might be variable in length. We have come to the conclusion that gaping goof-ups like this 
have happened, and continue to happen, because the system programmer types who implement 
these tools do not, and have never, used their work to write real applications. 
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Safe Hex 


No consideration of program-level database access would be complete without looking at how to 
keep from stubbing your database toes when all your users are running all your code against it 
simultaneously. The magic words are commitment control and journaling. 

To review some matters covered in prior installments, journaling is a process whereby your 
AS/400 automatically writes what your records used to look like and what your records are going 
to look like, along with the ID of your job and other pertinent notes, onto one or more journal 
files before actually making changes to your one-and-only, live, official database. For files that 
have a lot of change activity against them, journaling keeps you from losing more than just the 
transactions in progress at the time in case your software or hardware let you down. For 
relatively quiet files, especially large ones, journaling allows you a shortcut backup method. 

Instead of saving the whole file at frequent intervals, just save the changes. Dump out a new 
baseline backup version only when you start accumulating too much journal history to store 
comfortably. 

Searching For Commitment 

Journaling can be done in combination with the AS/400s normal record locking protocol, but it 
works most effectively in combination with commitment control. Commitment control is a little 
like the old 'Outer Limits' show ("We control the vertical. We control the horizontal.") getting 
ahold of your record locking logic. Normally, no matter how many files one of your programs 
may be using, at most, one record per file gets locked. These records, of course, are whichever 
ones your program happens to be processing from each file it has opened with update 
permission. Record updates to the actual database files are made in real time, as commanded by 
your program. 

Under commitment control, though, the AS/400s DBMS saves up any changes you may make to 
one or more records from one or more files until your program issues an explicit COMIT 
operation. Until that COMIT fires, the updates your program has computed and commanded are 
held in limbo by the system. 

A Wise Consistency 

There are a lot of situations in which one-at-a-time changes to your database file records would 
introduce temporary inconsistencies into the overall database. The trivial example is an operation 
in which you match a credit in one record's field — a general ledger account record, say — with a 
corresponding debit from a second such record's field. If you do these operations independently, 
your ledger file is out of balance between the time your first and second records get updated. 

A potentially more troublesome situation is the file that is intended to represent a tree-structured 
reality. If everyone's employee record has a field for the employee number of his or her boss in 
it, for instance, the company hierarchy will be encoded by the implied links between the "boss" 
fields of the records and the key fields of the boss' records. 

In a typical case, you would have to update quite a number of such records anytime anyone got 
promoted. If you did these updates one-at-a-time, you would have that same problem of 
temporary inconsistencies between the time of the first and last updates. Modifying multiple 
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records from the same file under commitment control, though, finesses the problem nicely. 
Summary 

Its foundation on a DBMS does not mean you cannot access your AS/400s files using programs 
employing conventional-looking, record-at-a-time file operations. Things haven't gotten that 
high-level yet. 

Long before the AS/400, in the bad old assembly-language-only days, programmers had to use 
many programming language statements to modify one record. Eventually, the idioms of 
assembly language became the primitive operations of higher-level compiled languages. 

Now you can manipulate one record at a time with a single code statement. You should, though, 
appreciate that this state of affairs is simply a step along the path to your computing future. Soon, 
the norm will be to manipulate many records at once, from one or more files, using single 
statements in high-level languages, such as SQL, whose primitives derive from idioms in our 
familiar compiled languages such as RPG. 

Finally, no matter how you may be manipulating your database records, looking out for their 
safety and consistency is always good practice. Your mother's advice applies to data processing 
too — dress warm, wear your mittens and fasten your seat belt. 
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The AS/400 and the System/38 are often referred to as "database machines." I remember how 
much confusion this caused me and my compatriots ten years ago when we first started with the 
System/38. Did "database machine" mean that data was not kept in files? What were these new 
things called "objects," anyway. Did that mean that we no longer wrote programs? Well, the dust 
settled quickly, and we found that we still had "files" and "programs," although there was now a 
lot more that we could do with them. I suspect that those of you who are new to the AS/400 have 
some of the same questions that we did back then. 

Despite the real and significant improvements that the AS/400 provides, data is, in the end, 
stored in files. More properly, we say that data is in "physical files," to distinguish the type of 
file used. You see, "file" on the AS/400 is a type of "object." The subtypes of this object can be 
physical, logical, display, printer and communication. This month, we will review some of the 
concepts and CL commands and "database commands" used with physical and logical files. 

In the Beginning 

I assume that you know how to use DDS to define physical files. If you are unclear about this, 
refer to the article in the Februaryl989 issue of DataNetwork, "Converting to External Files." 
Although you can create files that don't use DDS, and most CL commands don't care if you've 
used DDS to define the file, you will want to use "externally defined files" as much as possible. 

To create a new physical file, you use the CRTPF (Create Physical File) command. This 
command has many parameters, but there are only two required: the file name, and either the 
source file member containing DDS specs, or the record length of the file. If you are using DDS 
specs, you enter the name of the source member containing your file description, along with the 
name of the source file containing the member. You will virtually always store your DDS specs 
in a source member that has the same name as your proposed file. You do this, simply because 
there is no reason at all not to. Figurel-A shows an example of the "bare minimum" command 
used to create file PFEXAMPL. 


Next 


Home 


Previous 










If you store your DDS in a source member that has a different name, then you have to use the 
"SRCMBR" parameter on the CRTPF command, as shown in figurel-B. There will be some 
instances where you may create a file, using source with a different name, but for setting up your 
initial "database," you should strive for the simplest techniques available. 

As far as I'm concerned, there is one more "required" parameter, "TEXT." Use TEXT to attach a 
brief, 50 character description to the file. Just tell it like it is, plain and simple. If the file is your 
customer master file, put "Customer Master File" for the text. When you use the DSP or WRK 
commands to see lists of objects, the text will be there. 

Into The Thick of It 

Almost before you know it, you are thrown into the thick of things. You may find yourself 
having to make decisions about parameters when you don't have a clear understanding about the 
parameter or the future consequences. These decisions are very much a part of creating database 
files. Fortunately, you can quite easily change most of the parameters later, but you will probably 
feel more comfortable if you understand the options before you begin. 

One of the primary considerations you must understand about database files is the concept of 
"file members." You are already somewhat familiar with this, since any source statements that 
you create, for programs or DDS, are stored in "source members" of "source physical files." The 
question with database files is, do you want or need more than one member in the file? 

The answer, of course, is "it depends." To start with, you will need a member in the file before 
you can store any data in it. That is, the file that you create is, more or less, just a "shell," used to 
describe the data kept within it. You can create a file that has no members in it; in fact, that is the 
case when you create a "field reference file", which should only contain definitions of data. But 
for files that contain data, there must be a member. 

If you don't tell the system otherwise, it places into the file a member with the same name as the 
file when you create it. This is the only member allowed in the file, so any operations on the file 
actually take place on this one member. 

In many cases, that is exactly what you want to happen. However, there are many types of data 
processing situations where it is useful to have any number of members in the file. "Such as," 
you inquire? Most commonly, if you need to keep data for multiple companies, or perhaps 
different fiscal or calendar years. Think of situations where you have created "duplicate" files 
that have the same record layout but different file names. You can consider those to be 
candidates for "multiple membership." Of course, you can create duplicate files with different 
names if you want, but you may find it more advantageous to use multiple members. 

To me, one of the advantages of using multiple members instead of multiple files is that it 
reduces the amount of "clutter" on the system. It also reinforces the idea that you should treat the 
data the same. Because all members in a file share the same file definition, you know that you 
have the same type of data. You can also save and restore all the data with only one name, rather 
than using the names of each file. 

You will have to decide which method you want to use. Most people coming from the System/36 
seem to prefer using separate files, since that was the only practical S/36 option. It may help to 
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think of a multiple-member physical file as a "collection" of files, since that is how the system 
treats it. There is no danger of the system mixing up the data, since all operations are done using 
a specific member. Using CL commands, you identify the member that you want to use. 

Members Only 

Now return to the CRTPF command and turn your attention to the MBR and MAXMBRS 
parameters. Use the MBR parameter to assign a name to the first member in the file. The default 
is to assign the same name as the file. If you know that you are going to use the file as a multiple 
member file, you should probably use MBR(*NONE) as the name. That tells the system that you 
don't want to add a member just now; you will add it later with the ADDPFM (Add Physical File 
Member) command. 

If you are going to use a multiple member file, you should specify the MAXMBRS (maximum 
number of members) parameter as MAXMBRS(*NOMAX). You can specify a specific number 
for MAXMBRS, for example, MAXMBRS(IO), but I can't think of any reason you would do 
this. I've always used either MAXMBRS(l) or *NOMAX, and tend to create all files with 
*NOMAX. (By the way, *NOMAX really means 32,767, the system maximum. Supposedly, no 
one will ever need more than that many members.) I specify *NOMAX so that I don't have to 
deal with annoying messages later, telling me that I can't add another member because the 
maximum number of members is already in the file. S/36 people may have some reluctance to 
specify *NOMAX, thinking that they will consume precious disk space. That is not the case. 
Space is not consumed until it is needed; more about this soon. 

Closely allied with the MAXMBRS parameter is the SIZE parameter. This lets you specify how 
many records you want to allow each member in the file to contain. This parameter has a little 
song-and-dance about the initial size, the increment size and the number of increments, but you 
can avoid all this by just specifying S IZE(*NOM AX). In this case, *NOMAX stands for 
16,777,215.1 guess the intention behind the SIZE parameter is to prevent "run away" programs 
from consuming all your disk. For example, you may have a program that goes into an endless 
loop, and writes records on each pass through the loop. If you believe that this could be a 
problem, then by all means, use the SIZE parameter. Be aware, though, that the problem with 
SIZE is usually that you run out of room in a properly working program. That is, a program goes 
to add records to the file, and reaches the upper limit, with all the extensions. The system sends a 
message to your terminal, or in the case of batch jobs, to the system operator's terminal, giving 
you the option to expand the file by an additional increment or cancel the job. This is somewhat 
of an annoyance when everything is working properly, and can be avoided by specifying 
SIZE(*NOMAX). Again, this does not take up any space until the records are written to disk. 

You Have Better Things to Do 

There are three parameters that I call the "bonehead" parameters, and I can't think of any 
practical reason ever to use them. I have no doubt, though, that somebody will insist on using 
them, so let's cover them now and forget them. The first parameter is "ALLOCATE". This tells 
the system to go ahead and take up the amount of space specified in the SIZE parameter. 
Fortunately, you can't use this if you specified SIZE(*NOMAX). The only possible use I can see 
for this parameter is similar to the S/36 "//IFBLOCKS" construct, where you need to determine if 
you have enough available space before you begin. It seems to me that this is a last-resort on the 
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AS/400. The AS/400 uses more disk for more uses than you can imagine; storing data files is just 
one use. If you're cutting it that close on your system, then you better order more disk without 
delay. 

The second parameter, "CONTIG," tells the AS/400 to allocate contiguous space. Theoretically, 
this might give a performance improvement for sequential access. Real world: forget it. The only 
condition that I can imagine where this would make any difference is if you use this when there 
is only one job running, and only the file using CONTIG is used. 

The third bonehead parameter, for which I can't imagine any use, is "UNIT." This tells the 
AS/400 the preferred disk unit that you want to use. Why? Who cares? Don't! 

So forget about these parameters. You should never use them. You will find this theme recurring 
in this series of articles, and the sooner you learn it, the quicker you can get on to things that 
make a difference: there is no "silver bullet" on the AS/400, as far as performance is concerned. 
That is, there is not one factor that you can seize and say, THIS one will do it! In my experience, 
AS/400 performance is most affected by these factors in this order: number of active jobs in the 
system, environment used to run jobs, amount of main storage, division of main storage, number 
of disk arms, and so on. Programming for performance is a painstaking job, and you will never 
be able to tell if one technique is really effective. Learn to think of the AS/400 as the sum total of 
its current state. On a heavily used system, the current state is constantly changing, so things that 
affect performance at one time may actually impede it soon after. 

That brings up a discovery that you will make, sooner or later: the AS/400, like the System/38 
before it, is a well designed machine, and is quite capable of running itself to best advantage. If 
you give the machine enough resource to handle the workload that you demand, then it will 
probably run itself better than if you constantly tinker with the technique du jour. On the other 
hand, I do not mean to suggest that you completely ignore performance related issues. Just 
understand the totality of the situation, and don't think of any one option as being "the answer" to 
your situation. 

Other CRTPF Options 

There are other parameters of the CRTPF command that you should know about. These are not 
necessarily "bonehead" options, but on the other hand, you may never need to change the 
defaults. I will review these briefly. You should refer to the Control Language Reference manual 
for the CRTPF command to learn all the considerations of these parameters. 

There are several "performance" options that you may or may not want to specify. Among these 
are MAINT, RECOVER, FRCACCPTH, FRCRATIO, WAITFILE, WAITRCD, SHARE and 
DLTPCT. 

MAINT tells the AS/400 when to "maintain" the keyed access path for the file. If the physical 
file does not have any key fields, this parameter does not apply. Also, if the key values are 
unique, the only option is *IMMED. For virtually all files used with interactive programs, you 
will use the default of *IMMEDthe access path is updated every time a change is made that 
affects it. That is, if you add, delete or change key fields, the change is made immediately to the 
access path (S/36:"index"). The other options, *REBFD (Rebuild) and *DFY (Delay), tell the 
AS/400 to defer access path maintenance until the file is opened for use. You would use this for 
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batch jobs. For example, if one step of a batch job creates a work file that has an access path, you 
could specify that the access path is to use *REBLD maintenance. The system will then delay the 
next program in the batch job that opens the file while it rebuilds the access path. The advantage 
of this is that it is sometimes quicker to build an access path from scratch, or rebuild one in a 
separate operation, rather than maintain the access path as changes are made. I will mention this 
again in the discussion about logical files. There is no real harm done in using the default of 
*IMMED, and if the file is "small" (10,000 records or so?), there is probably no detectable 
advantage in using this parameter in a batch job. You should avoid using anything but *IMMED 
for files that can be used in interactive programs because the possible delay in maintaining the 
access path will be quite noticeable if you start a program that opens a file with *REBLD or 
*DLY maintenance. People are usually impatient when they start a program; they do not 
appreciate your forcing them to wait for access path maintenance. 

The RECOVER parameter tells the system how to recover the access path after a system failure. 
You'll have to read about this in the manual and come to your own conclusions. In my 
experience, recovery after system failure has always been a long drag, and I tend to doubt that 
tweaking this parameter will make a significant difference. But many of you have written to the 
DataNetwork BBS about your experiences with system failures and recovery, so you may want 
to try different options on this parameter. Again, this is only going to make a detectable 
difference with substantial files. 

Two related parameters, FRCACCPTH and FRCRATIO, tell the AS/400 how often to make 
changes on disk. You see, the AS/400 does not necessarily write access path or data changes to 
disk when your program does an output operation. Part of the optimization of the operating 
system is to wait until there is a significant number of changes to either the access path or the 
data base before performing disk I/O. In earlier times, we would have called this "buffering." 

The downside of this is that the system might fail before it records the changes on disk. If you 
feel that you must have all changes recorded immediately, you can change these parameters so 
that the system will record the changes as they occur. This has a potential negative impact upon 
performance, since you are requiring the system to perform more disk I/O than it would do on its 
own. Also, there are considerations about using these parameters if you are journaling the files. 
(Journaling is a means of recording all changes, in sequence, to the data base. I am not covering 
it this series; you can find out more about it in the Backup and Recovery Guide.) 

Use WAITFILE and WAITRCD to tell the AS/400 how long you want your programs to wait for 
the file or a record to become available. There are many reasons a file may not be available to 
your job: it may be in the process of backup or restore, it may be in the process of being cleared, 
and so on. The default for WAITFILE is *IMMED, meaning that the program will not wait for 
the file to become available. What does that mean to you? It means that if you try to use the file, 
and it is not available, your program will receive a message telling you that you can't have it. As 
with any message of this type, if you don't do something graceful, the system will give you one 
of the "line drawing" messages across the top of your screen. You can usually try again to 
allocate the file, or cancel the job. Hopefully, you will have some way to recover from this type 
of message, and build it into your programs, since most users treat the "line" messages as the 
kiss-of-death. Lacking anything better to do, they may press ENTER without entering a 
response, which defaults to the CANCEL option. That might not be what you want them to do. 

The WAITRCD (wait for record) parameter tells the AS/400 how long you want to sit and wait 
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for a record to become available. This is only an issue if the file is opened for update or if you 
are deleting a record. The default wait time is one minute. You will occasionally see this happen: 
you will be sitting there, using your program that has always worked, and suddenly it will just 
freeze. After the minute is up, if the record is still not available, you will get a line drawing 
message, then you will know exactly what the problem is. The cure for this type of problem is to 
design your programs so that a record read for update is never locked. 

How do you handle these troubles? For the WAITFILE condition, you can use the ALCOBJ 
(Allocate Object) command before doing anything else significant in the program. If you can't 
allocate the file for the purpose that you require, then you can bail out at the beginning or go into 
a "retry" loop and see if you can allocate it later. You may want to use the WRKOBJLCK (Work 
with Object Lock) command to see what job has the file tied up. Perhaps you will find that 
somebody has wandered away from their terminal without signing off. This seems to be a 
popular problem, as callers register many complaints on the DataNetwork BBS about this. I 
understand that Release2 of OS/400 will have some options to automatically drop terminals after 
a certain amount of inactivity, so there may be some relief there. If you don't use the ALCOBJ 
command to try to "preallocate" the file, at least include MONMSG (Monitor Message) 
commands so that your program will intercept the error message, rather than having the message 
go through to the user. If you get the error message, you can tell your program to do something 
else, such as end or retry, rather than depend upon fate and your users to get correctly out of the 
jam. 

Lor the WAITRCD option, you can probably code error handling right in your application 
program. Lor example, if you are using RPG, you can use the "less than" indicator position to set 
on an indicator if there is an error when you attempt a file operation. That is, for example, if your 
operation is CHAIN, you would use the "no record found" indicator in positions 54-55, and right 
next to it in positions 56-57, use the same or another indicator for "some error happened." If you 
want to get explicit, you can use the program status data structure and file information feedback 
to determine the exact error condition. Usually, you can just use the "less than" indicator, and 
send some message to the user. 

Use DLTPCT to tell you when there is a given percentage of deleted records in the file. You 
specify the percentage for which you want to check; the system informs you when it reaches the 
percentage by putting a message in the system history log. Presumably, you could manually or 
programmatically check the system history to find the message. You would care about this if 
your file is volatile, in terms of the number of DELETE operations that you perform on it. Lor 
example, to delete a large number of records from a file, you would want to perform a file 
reorganization to purge the deleted records. You see, when you delete a record, the space taken 
by the record is still used in the file, although you can't use it again (in most usual cases). This 
has a negative impact on performance, especially if the file is read sequentially, since the system 
reads deleted "records" also. By reorganizing the file, with the RGZPLM command (Reorganize 
Physical Pile Member), you recover the unusable space for other purposes, and you potentially 
improve performance when using this file. 

The SHARE parameter, one of the few that I feel has a real and detectable impact upon 
performance, will be covered soon. 

Prom this review of parameters used on the CRTPP command (and many of them are used for 
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the same purposes on the CRTLF command), you can see that I seldom recommend using 
anything other than the defaults. If you are just getting into creating your AS/400 database, use 
the defaults for now. You can use the CHGPF (Change Physical File) command to change most 
of the parameter options later. 

A Logical File Is... 

A logical file is nothing more than a means of accessing a physical file. The primary features of a 
logical file are its access path and its scope. Access path refers to selection and key sequencing 
of records. Scope refers to the physical file members included in a logical file member. 

You will probably use your first logical files simply as "alternative index" files. In this case, they 
work the same as on the S/36. A change to the logical file, or to the underlying physical file, 
causes a change to this and other associated logical files. This is not quite as revolutionary a 
concept, now that everybody is accustomed to alternative index files and various PC database 
programs, but ten years ago, when the System/38 was new, this was a very big deal. In fact, most 
logical files are still used simply as alternative index files, and to a large extent, they have 
obviated the need to perform sorts for batch processing. 

The main problem with logical files, from the system's point of view, is that they tend to 
proliferate. Controlling logical files is one of the areas you should focus your attention on, when 
you are looking for ways to improve performance. The reason is, quite simply, that a change to 
the underlying physical file that affects the access paths has to be recorded in the associated 
logical files. So if you have ten associated logical files and perform an update to the physical file, 
you potentially have to "update" eleven files, not one. The system is very good about this, and I 
have never seen it complain about having too many logical files. In interactive programs, you 
will probably not notice drastically better or worse performance, say, between no logical files 
and up to twenty. You will, however, notice a great difference when you run batch programs that 
perform lots of I/O on the files. For example, if you are creating batch work files of perhaps 
100,000 records, the performance difference might be measured in hours, depending upon 
whether logicals exist over the physical. To put it another way, if you are programming a batch 
job and you have a choice, create and fill the physical file first, then create the logicals over it. 

Do that rather than create the physical and the logicals first, then fill the physical. It seems that 
creating a logical file is many times faster than maintaining it. You notice the difference in batch 
jobs because of the number of transactions that occur. 

The "scope" of a logical file can be simple or quite complicated. In most cases, you will use the 
simplest form available: that is, you will build a logical file member over one associated physical 
file member. Think back to the example of using different physical file members to hold 
information for different companies. It probably wouldn't make sense for the scope of the logical 
file to include more than one member (company). It does make sense, though, to have a 
corresponding logical file member for each physical file member. Your program, by using one of 
the logical file members, is actually working with data contained in the (one) underlying physical 
file member. 

The scope becomes more complicated when you create a logical file member that uses more than 
one physical file member. I will have to leave it up to you to determine when you would do this. 
One of the better diagrams depicting this type of logical file is shown on page 6-18 of the Data 
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Base Guide. You should review the entire section on "Logical File Members," since they have 
the pictures and discussion of how you use these techniques. 

Adding On 

The nice part about setting up your physical and logical files, especially if they are multi-member 
files, is that it is very easy to add additional members to them. You use the ADDPFM (Add 
Physical File Member) and ADDLFM (Add Logical File Member) commands to add members to 
the files. For example, if ABC Company is keeping annual members in their files, they might 
have members ABC88 and ABC89 already in the file. They can add next year's member with the 
ADDPFM command, shown in Figure 2A. 

That's all for the physical file. The new member has all the properties of the other members, as 
defined when you created or last changed it: the same record format, member size, and so on. 

You would add an associated logical file member with the ADDLFM command (Figure 2B). 

That associates the logical file member "ABC90" with the corresponding physical file member, 
and only that member. 

You can review the associations between physical and logical files with several CL commands. 
These commands are DSPDBR (Display Data Base Relations), which shows the names of logical 
files built over a physical file. The DSPFD (Display File Description) command can be used with 
a logical file to show the names of the logical file members and the physical file members over 
which they are built. So you should never become "lost" when you set up your database. Even if 
the number of file objects becomes quite large, you can use these commands to review the status 
of these objects. 

The Only One For Me 

So, suppose you've set up your database. You have quite a few physical and logical files; there 
may be quite a few members in a file. One thing is for certain: when you use a program that 
refers to one of your files, one of the members will be used, since all database I/O is done against 
a particular member. The obvious problem is, how do you tell it which member you want to use? 

In the absence of any contrary direction, the system uses the first member of the file. With single 
member files, you're home free, since that is exactly what you want. When you have multiple 
members, you "point" the system where you want it to go. The "pointing" is done with the 
OVRDBF (Override with Database File) command. The relevant parameter is MBR, where you 
can explicitly name the member that you want used. 

At this point, we might as well review another option you can use, in case you decide you don't 
want to go with the multiple members approach. If, instead, you decide upon separate physical 
files, you use the OVRDBF command to point to the file that you want to use. For example, if 
you have an RPG program that uses file "PFFILE" in the F-spec, and you want to use file 
"PFFILEA" for a run, you would use OVRDBF to point to that file (Figure 3A). 

That is, PFFIFE is the name that your program uses to refer to the file. The override tells OS/400 
to "connect" your program to "PFFIFEA" when "PFFIFE" is opened. This is similar to the 
System/36 technique of using the FIFE statement, shown in Figure 3B. 
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Of course, you can use the TOFILE and MBR parameters if you need to; they aren't mutually 
exclusive. For example, you might need to use something similar to Figure 3C. 

The point to remember about members is that a program will use the first one in the file unless 
you tell it otherwise. 

In a compiled CF program, you can use CF variables for each of the parameters on the OVRDBF 
command. Using that technique, you can create a program that overrides any number of files to 
the correct members, and pass the override-to name as a variable. For example, you might have 
an override as in Figure 3D, where &OVRMBR could be passed to the CF program. 

When You Don't Know Where You're Going 

Usually, you will know which member to use before starting the program that uses it. In that 
case, you perform the OVRDBF commands, then call the program that uses the files. Sometimes, 
though, you might not be able to determine the members to use until you get into the program. 
That poses somewhat of a problem, since the program (in RPG) automatically opens and 
connects the file to the first member, unless you take other steps. 

If you know that you will be getting into this situation, you can take matters into your own 
hands: you can control when the files are opened, and you can override to a member from within 
the program. Understand, I'm not suggesting that you adopt this as your usual method, but only 
when the circumstances leave you no alternative. 

For RPG programs, you code the characters "UC" in positions 71 and 72 of the F-spec for the 
file that you need to control. The "UC" stands for "user controlled," and means that you will tell 
RPG when to open the file. Refer to page 2-6 of the RPG/400 Reference. Note that you can only 
use this technique with Full-Procedural files. 

Before opening the file, you determine the name of the member that you want to process. You 
can determine this by any means at your disposal: calculation, user input, or whatever. In any 
event, you need to have the name of the member available. You construct a character string, 
probably using a work array, that will be your OVRDBF statement. You can store the "shell" of 
the OVRDBF statement, as shown in Figure 4A. 

Feave ten spaces in the MBR parameter, since that is the maximum length for the member name. 
When you determine the member name, plug it into the work array, perhaps as in Figure 4B. 

That is, move the member name into the MBR parameter, immediately after the first parenthesis. 
The point of constructing this command is so you can tell the system which member you want to 
use. If you are in an RPG program, you can issue this type of command with the QCMDEXC 
program. At this point, go to page 6-1 in the CF Programmer's Guide, and read the section about 
that command. In your RPG program, you call that program as shown in Figure 4C. 

That is, you call QCMDEXC, passing the command that you want it to process and the length of 
the command that you are passing (it's OK to have the length be longer than the command, but 
don't use a shorter length). Using this example, your RPG program passes the OVRDBF 
command, which tells OS/400 the name of the member that you want used when your program 
opens the file. Immediately after the CAFF construct, you can open the file (see Figure 4D). 
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Because there is an override in effect for the file, that override is used when you explicitly open 
the file. 

If you want to get fancy, you can open different members during the same run of the program. 
You would first CLOSE the file, then use the CALLQCMDEXC construct, then OPEN the file 
again. 

The more astute readers, at this point, are wondering why we need all this tricky programming in 
the first place. Why not just call a CL program that performs the override, using the regular CL 
OVRDBF command? The reason has to do with "invocation level." That is, if our RPG program 
is invocation levell, and we call a CL program, then the CL program is at invocation level2. Any 
overrides done at that level apply to that level or lower. The lower the invocation, the higher the 
number. Got it? When the CL program returns to the RPG program, we are back at invocation 
levell, where the CL override does not apply. QCMDEXC gets around this little problem by 
operating at the same invocation level. I know, it sounds bizarre, but that's how it works. 

A Little Goody 

I promised you earlier that I would tell you something that you can do to improve performance, 
or at least, the perception of performance. I say "perception" because this technique is most 
noticeable in interactive jobs, which is exactly where you want perceptions to be correct and 
wholesome. 

The big secret is the SHARE parameter, or more correctly, the concept of sharing ODPs (Open 
Data Paths). The whole issue of performance, perception and shared ODPs is the result of the 
AS/400's ability to have one program call another. Chances are, within an application, the called 
programs will refer to the same files. For example, it would not be extraordinary to have an 
Order Entry application that has ten programs that can call each other, and use many of the same 
files (Customer Master, Order Header, Order Detail, Codes, etc.). Now, picture the situation: 
program OEOOl uses five of the files. When you start OEOOl, it opens all five. Before long, 
OEOOl calls OE002, which also uses the same five files, plus two others. On the first call, 

OE002 has to open the five files for its use, plus the two others. So OE002 opens seven files in 
all. This continues, as one program calls another, each opening the same files all over again, until 
finally all the programs have been called. At that point, you have a rather tremendous amount of 
overhead (PAG, or Process Access Group) in effect. The situation may be worsened if one of the 
called programs returns with LR set on. When it returns, the files that it opened are closed. If it is 
called again, it has to go through the exercise all over. 

There are a couple of problems here. These are usually not "show stoppers," in that there is no 
imminent danger of crashing the system; it's just that things are not quite as nice as they can be. 
The problems are that there is a tremendous amount of duplication going on. Each program is 
opening an ODP to the same file member, yet each program is operating as if in a vacuum. This 
duplication shows up in response time: when one of the programs calls another, there is a 
noticeable delay on the first call, while that program goes through the opening routine. The 
second problem, and one that you should concern yourself with, since it relates to the "totality" 
of the machine, is that this duplication results in the job using more machine resources than 
necessary. When you start hanging dozens of terminals on your machine, and each job running at 
those terminals creates the same situation, you are asking the machine to keep track of a huge 
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amount of job control information. 


So, the magic is to use the "SHARE" option. But, not by specifying SHARE(*YES) on the 
CRTPF or CRTLF command. To understand why you should use SHARE, and why you don't 
use it on the CRT command, let's look at what it does. 

The SHARE ODP option tells OS/400 that you want it to use the same ODP for a file within the 
same job. Did you catch that... within the same job. That means that Group Jobs will have their 
own separate ODPs, so there will still be some potential duplication if you are using group jobs. 
Using the same ODP means that the file only has to be opened once. 

Think of this picture, to try to understand shared ODPs: 

You work with five other programmers (this represents five programs that can call each other). 

Each of you has the complete set of AS/400 manuals, all 40 dozen of them (this is all the files 
that you can use). Whenever you program, you can only work at one table in the programming 
room, but for some odd reason, only one of you can work at a time (this represents the active 
job). However, you are quite fast at jumping up and down from the table, so somebody else can 
work (one program calling another). 

Now, imagine that you go into work at the table, and you bring in five of the manuals with you. 
Before you can do anything, you have to find the manuals, get them from your shelf, bring them 
to the table and open them to the section you want. That is "opening the file." Before you know 
it, you have to call in your friend to work on his section of the program, so you jump up and run 
out. He runs in, bringing seven manuals. Oddly enough, five of the seven are the same manuals 
that you lugged in, but he doesn't know that, so he's brought in the same plus two others. That 
represents what happens when you call another program, without shared ODPs. He has to go 
through the "findingthesection" routine, and so on. He calls his buddy. The same thing happens 
again. Soon, it is your turn to come back in. This time, the table is a mess, covered with manuals. 

In order to get some work done, you have to take some of the manuals off the table. That 
represents "paging," of a sort, in that you substitute something that was there for some work 
space. 

I Think You Get The Idea 

Now, if you used shared ODPs, the scenario would work like this: 

You come into the room, with your five manuals. You open them to the section that you need, do 
your bit of work, then go out. Your friend comes in, but this time, he only needs to bring in two 
manuals and open them, and then start working. Since he sees your manuals there, and decides 
that they are the same ones that he needs, he uses them. Although you left your RPG manual 
open to page 10-10, he needs to read page 4-15, so he turns to that. When he is done, he leaves 
the room. Your RPG manual is still at page 4-15. When you come back in, you need to review 
page 10-10 again, so you turn to it again. 

In a nutshell, that's "shared" ODPs. You probably noticed that there is a potential problem with 
shared ODPs, which is usually not a problem in an interactive environment. That is, you left off 
at one point in the manual (file), and when you came back to that manual, you were at a different 
point, courtesy of your friend (another program). The reason this is not usually a problem is 
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because you can simply turn again (CHAIN) to the page that you want. 

However, if you were reading the file sequentially, called another program, then came back and 
continued the sequential read, there is no guarantee that you are reading from the point where 
you left off. It is as if you started reading chapter 10, ran out, and when coming back didn't 
notice that you were in chapter 4, but continued reading anyway. One solution is not to call 
another program in the midst of sequential processing, if there is a chance that the other program 
will reset the position. Another is to always reset the position before you start using the file 
again. Still another technique is not to allow sharing of that particular ODP, or to allow sharing 
between some of the programs, but not all of them. 

Another little complication that you will encounter reads something like this: "the first time the 
file is opened, all the open options subsequently needed must be specified." Huh? Well, that 
means that if the first program opens the file, and only references it as an INPUT file, the second 
program, using it as UPDATE, is going to bomb. Why? Because the first program opened the 
file for INPUT only. The second program tries to share the ODP, finds that it can't and proceeds 
to quit. The trick is, you have to open it, on the first open, as an UPDATE file. 

Now how are you going to do that? It doesn't make much sense to have to recompile a program, 
just to include the UPDATE part of the open. It turns out that there is a CL command, OPNDBF 
(Open Data Base File) that you can use and specify how you want the file opened. The options 
are *INP, *OUT and *ALL, for input, output, and ALL (input, output, update, delete). For the 
life of me, I can't think of any reason you would open it as anything other than *ALL, but if you 
know a file will only by used for input or output, you can specify that. The normal use of the 
OPNDBF command is in a CL menu. That is, if you call a CL program to display the Order 
Entry menu, you would include the OPNDBF commands before displaying the menu screen. The 
program processes the opens and displays the menu. When an option is selected, things go that 
much quicker because the files are already opened. 

This is the type of thing that sounds like too much work to be worthwhile, but if you will try it, 
you will probably see that there is a noticeable difference in the appearance of response time. To 
use this well, you should probably make up a chart of your programs, and diagram how programs 
call each other, and how the programs use the files. If you can share the most commonly used 
files, you will get the benefit of the shared ODPs. If you find a situation where you don't want to 
share an ODP for one of the programs, but other programs would benefit from the sharing, you 
can prevent the one program from participating in the share by using the OVRDBF command. 
That is, if program "B" should not share a file, put "B" into a CL program, for example "CLB". 

In "CLB", put an override statement (see Figure 5). This tells OS/400 that you do not want 
FILEA to use the SHARE option. The SECURE parameter tells OS/400 that you don't want any 
other OVRDBF commands to "override" this override. 

A file that is used in only one program will not help, in terms of sharing its ODP, but you can 
still use the OPNDBF command to "preopen" the file before the program using it is called. 

You should read all the section in the Data Base Guide pertaining to this subject, starting on page 
8-7. 

You can also share display files in a job. This has a spectacular effect on performance, since it 
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turns out that opening a display file takes about twice as long as opening a file. You specify 
display file sharing on the CRTDSPF or OVRDSPF command. We'll cover this in more detail 
next month. 

Now Think About This 


This article is perhaps the roughest going yet. Unfortunately, it has only "skimmed the surface;" 
there is still quite a bit that you will discover about how the AS/400 uses the database. It is not 
possible to include many figures and illustrations with this article, since it has been more 
conceptual this month. 

But you now have a number of directions that you can go in. I urge you to get into the manuals, 
especially those that I referenced, and read the sections pertaining to these concepts. If it doesn't 
make sense at this point, don't despair. Continue reading. Don't force yourself to understand, 
instead, just try to remember where you see material. Soon, all this will start to make sense, the 
pieces will fit, and you will begin to understand what a truly incredible piece of work OS/400 is. 


Figure 1 Create file examples 


Create File Examples 


Example A: 

CRTPF FILE(QTEMP/PFEXAMPL) SRCFILE(QGPL/QDDSSRC) + 

TEXT ( '.' ) 

Example B: 

CRTPF FILE(QTEMP/PFEXAMPL) SRCFILE(QGPL/QDDSSRC) + 
SRCMBR(DONTDOTHIS) TEXT('.') 


Figure 2 Add member commands 

Add Member Commands 

Example A: 

ADDPFM FILE(PFFILE) MBR(ABC90) + 

TEXT('ABC Company 1990 member') 

Example B: 

ADDLFM FILE(LFFILE) MBR(ABC90) + 

DTAMBRS((PFFILE ABC90)) 


Figure 3 OVRDBF to a file and member 

OVRDBF to a File and Member 

Example A: 

OVRDBF FILE(PFFILE) TOFILE(PFFILEA) 

Example B: 

// FILE NAME-PFFILE,LABEL-PFFILEA 
Example C: 

OVRDBF FILE(PFFILE) TOFILE(PFFILEA) MBR(MBRl) 
Example D: 

OVRDBF FILE(PFFILE) MBR(&OVRMBR) 


Figure 4 Using QCMDEXC in RPG 

Using QCMDEXC in RPG 

Example A: 

OVRDBF FILE(PFFILE) MBR( ) 

Example B: 

MOVEAMBRNAM AR, 25 
Example C: 

Z-ADD35 LEN 155 

CALL 'QCMDEXC' 

PARM AR 

PARM LEN 

Example D: 

OPEN PFFILE 
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Figure 5 OVRDBF, no SHARE, SECURE 

Figure 5 

OVRDBF, no SHARE, SECURE 
OVRDBF FILE(FILEA) SHARE(*NO) SECURE(*YES) 
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by Mark Fleming 

Sometimes, you have got to dig deep to find the power lurking within the AS/400. Aggressive 
exploration often results in discovering tools that are more powerful and flexible than those that 
first appear on the surface. One such unearthing is the SORTDB (Sort Database File) command 
buried deep in the yet-uncelebrated QUSRTOOL library. 

SORTDB contributes a convenient command interface to the FMTDTA command. For those of 
you coming from the System/36 who are unacquainted with FMTDTA, it is essentially the same 
as S/36 #GSORT. Sort specification statements which are nearly identical to those of #GSORT 
are set up in a source member which is referenced by FMTDTA, and the input file is sorted 
according to these specifications. 

Why SORTDB? 

Why is SORTDB an attractive surrogate for FMTDTA? First of all, understand that SORTDB 
does not actually do away with FMTDTA. It is more precisely a simplified front-end to 
FMTDATA. Rather than setting up the position-dependent, cryptic sort specifications that 
FMTDTA requires, you more intelligibly submit your sorting requirements to SORTDB via 
command parameters. SORTDB then performs its utilitarian duty of creating and executing the 
sort. (Take a quick glance at Figure 2 for an idea of what a SORTDB command looks like.) 

In addition to the more human interface, SORTDB provides other advantages as well. One major 
drawback of FMTDTA is that it does not work with externally described field names. All fields 
referenced by sort specifications must be identified by their physical positions in the record. This 
is not a practice that is consistent with the AS/400 database scheme. SORTDB observes the 
database methodology and will work with fields from externally described files. This is an 
important consideration since files are subject to structural changes and there is no easy way to 
have the FMTDTA sort specifications dynamically mirror these changes. 

Along with the possibility of a change in the file's structure, there are other needs for dynamic 
changes in the sort specifications. These include such things as the current date, user ID, or any 
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user-input variable sort/selection criteria. Since SORTDB's specifications are described in 
parameters, variable fields are easily substituted. 

The functional benefits should be enough to convince you to use SORTDB. But there is one 
other inducement—that is that SEU does not have a format that supports the FMTDTA source 
member specifications. Using FMTDTA forces you to refer to the manual as you create the 
source member. 

SORTDB provides support for the simple sort and select functions that are required for most 
tasks. If you need to go beyond what SORTDB gives you, it is still useful to you by acting as a 
"FMTDTA Source Generator." You can tell SORTDB to create a FMTDTA sort specification 
member as per your request, but not execute it. This will provide a starting point from which you 
can add to the source member for later use with FMTDTA. 

SORTDB accepts either a physical or logical file as the input file. If it is a logical file, it can only 
have a single format. The first member of a file is read unless otherwise named. 

A FIFE sort is assumed for SORTDB. This means that the entire record of each record that 
SORTDB selects is placed in the output file. 

Get Down To It 

Enough introduction. Fet's get down to the nitty-gritty. SORTDB is not an OS/400 command, 
but it is written by IBM. It is part of the QUSRTOOF library, which includes more than 80 other 
useful application development and system management tools. (For a complete description on 
this special library, see "Free AS/400 System Management Tools—Compliments of IBM", 
DataNetwork, May 1989, or your RESOURCEFIBRARY.) 

QUSRTOOF only contains the source code for each tool. The objects must be compiled into a 
library named TAATOOF. I am not going to go into too much detail on the library in this article, 
but give just give you enough instruction to create SORTDB. Key the commands shown in 
Figure 1 to create the TAATOOF library, the CRTTAATOOF command (necessary to create a 
tool), and the SORTDB command. You'll need Security Officer authority to run 
CRTTAATOOF. 

Add TAATOOF to your library list and you are ready to use SORTDB. You can prompt for its 
parameters with F4, but more than likely you will be using the command in a CF program as a 
front-end to a batch program. 

I will briefly go over the parameters and offer a couple examples. You can find a complete 
description of SORTDB in member SORTDB of file QATTINFO in the QUSRTOOF library. 
Refer to this member for complete parameter rules. 

General Keywords 

INFIFE: Qualified name of the input file to be sorted. 

INMBR: Input file member to use. 

EXECSORT: *YES will execute the sort. *NO will build the sort, but not execute it. 


Next 


Home 


Previous 








PRTSPECS: *YES will print the sort specs, *NO will not, and *ERROR will print only if 
FMTDTA fails. 

OUTFILE: Qualified name of the output file. 

NBRRCDS: Number of records to be read from the input file (useful for testing). 

OUTMBR: Member of the output file to use. 

OUTSRCF: Name of the source file to hold the generated FMTDTA specs. Default is 
QTEMP/FMTTMP. 

OUTSRCMBR: Name of the source member to hold the generated FMTDTA specs. Default is 
FMTSPC. 

Sort Keywords 

SORTFFD: A list of up to 10 field names in major to minor sort order. 

SEQ: A list of As and Ds, denoting, according to their respective positions in the list, if the 
SORTFFD entries should be sorted in ascending or descending sequence. If all are ascending, 
this entry can be left blank. 

Selection Keywords 

You can make up to four selections with SORTDB. These are specified with the SEFx and 
ANDORx keywords, where x is the number of the selection. For example, the first selection uses 
SEF1, the second uses SEF2, etc. 

SEFx: A keyword parameter list of: 

Field name: The field to be selected 

Relational operator: *EQ *NE *FT *FE *GT *GE 

Constant: Up to 20 characters 

ANDORx: Specifies the relationship between the x and x+1 selections. The default is *AND, 
which signals an AND relationship. *OR means an OR relationship. 

Now, let's clear up all the confusion with some examples. Figure 2 sorts FIFEA in ascending 
sequence of FFD1, followed by descending sequence of FFD3. FFD7 must not be equal to "A" 
or "B" and FFD8 must be greater than 100. Program PROGA will read the output file 
QTEMP/SORTOUT (the default file name), using FIFEA's format. 

You are all smart enough to not need more figures to showcase each different keyword. Figure 2 
should be enough to give you the idea. So let's jump right to something that is more complex. 
Figure 3 shows how you could code SORTDB to extract only records where field FFDA of 
FIFE1 is equal to the current date. Since the SEFx keyword only allows a constant, we have to 
create a command line with the literal value of the system date inserted into the SEF1 parameter. 
Then the program must call QCMDEXC to execute the created command line. 
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Considerations 


Obviously, if you need more than four selection statements, or other things that SORTDB cannot 
provide, you must use FMTDTA directly. But at least you can use SORTDB to create the basic 
sort specification for you as a beginning. 

There are also other considerations. Should you use logical files, OPNQRYF (Open Query File) 
or SQL instead? It depends. If you have more than a couple thousand records to be sorted and 
processed by a batch-type program, you will probably find that it is fastest to use SORTDB (or 
FMTDTA) in combination with a program that reads the output file in arrival sequence. Very 
complex selection routines and other auxiliary requirements could do best with other methods. 


Figure 1 Creating the SORTDB command 

Creating the SORTDB Command 

CRTLIB LIB(TAATOOL) 

CRTCLPGM PGM(TAATOOL/TAATOLAC) SRCFILE(QUSRTOOL/QATTCL) 
CALL P GM(TAATOOL/TAATOLAC) 

CRTTAATOOL TOOL(SORTDB) 


Figure 2 A simple SORTDB example 

A Simple SORTDB Example 

SORTDB INFILE(FILEA) SORTFLD(FLD1 FLD3) SEQ(A D) + 

SEL1 (FLD7 *NE A) ANDORl(*OR) SEL2(FLD7 *NE B) + 
SEL3(FLD8 *GT 100) 

OVRDBF FILEA TOFILE(QTEMP/SORTOUT) 

CALL PROG1 


Figure 3 SORTDB with a variable for a selection value 


DCL 

DCL 

RTVSYSVAL 

CHGVAR 

CALL 


SORTDB with a Variable for a Selection Value 
VAR(&CDATE) TYPE(*CHAR) LEN(6) 

VAR(&CMDLINE) TYPE(*CHAR) LEN(100) 

SYSVAL(QDATE) RTVNAR(&CDATE) 

&CMDLINE('SORTDB INFILE(FILEA) SORTFLD(FLDA) + 

SEL1(FLDA *EQ ' *CAT &CDATE *CAT ')') 

QCMDEXC PARM(&CMDLINE 100) 
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For those of you who have worked with subfiles, you know that the system automatically 
displays a message ("Roll up or down past the first or last record in file") when trying to roll 
beyond the beginning or end of the subfile. It is great that the system handles this automatically, 
but you may want your program to control what happens in this situation instead. 

Here is an example: You have a inquiry program that scrolls through a 100,000 record file. Since 
the file is so large, and the user would probably not scroll through more than a few pages of 
records before reselecting another starting point, you do not want to place all the records into the 
subfile. The efficient method is to request the starting point of the display from the user. When 
the user submits the string, the program creates a small subfile that contains, let's say, 10 pages 
worth of records. When the user tries to scroll past the 10th page or in front of the first page, you 
don't want the system to issue the standard message. You want the program to recognize the 
condition and create a new subfile for another 10 pages of display. In other words, the user could 
smoothly scroll through the entire file, never being aware that small subsets of the entire file 
were continually being loaded to subfiles and read. 

The solution is quite simple. All you have to do is use the ROLLUP and ROLLDOWN keywords 
in your subfile control record format (the format that immediately follows the subfile record 
format and uses the SFLCTL keyword). This will inhibit the standard error messages and return 
control to the program when trying to scroll outside the extents of the subfile did. 

The program makes you aware of this condition by setting on the indicators associated with 
ROLLDOWN or ROLLUP indicator in the format. When the ROLLUP indicator is on, you can 
refill your subfile with next 10 pages worth of records. When the ROLLDOWN indicator is on, 
you can refill the subfile with 10 pages of records, starting one page earlier than the last subfile 
load. 

We used 10 pages of records as an example; you could code your subfile to any size you like. 
(For more information on subfiles, refer to the DDS Reference manual, SC21-9620). 
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Former System/36 RPG II programmers that are now on the AS/400 will find that RPG/400 
offers more flexibility in multiple field key file processing. 

On the S/36 you have to chain to the multiple-field-key file with a field that is equal in length to 
the total key length. With RPG/400 you can also chain to the file with a field that is equal in 
length to the first field of a multiple-field-key. In essence, if factor 1 of the CHAIN operation is 
equal in length to the first key field, it will chain as if the file only has the first key field in the 
index. If there is no match, the indicator in columns 54-55 turns on. 

Why is this useful? Consider this example: Let's say you have an invoice file with a key made up 
of customer number and invoice number. You want to check the invoice file for the existence of 
any invoice records for a customer. On the S/36 you have to set up a field with the same length 
as the file's key, perform a SETLL operation with the customer number left-justified in the field, 
perform a READ operation, and finally compare the requested customer number to the customer 
number in the retrieved record. If the compare is equal you know that there is at least one invoice 
for the customer. 

With RPG/400 all you have to do is CHAIN to the invoice file with the customer number in a 
field that is the same length as the first key field. If the indicator does not come on it means that 
there is at least one record in the file with the same customer number. 
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by Midrange Computing Staff 

Unlike the System/36, source members are very easy to process within programs on the AS/400. 
Source physical files are automatically externally-described with three field names. For example, 
the external field names for file QRPGSRC (source file containing RPG source members) are 
SRCSEQ, SRCDAT, and SRCDTA. To find out the external field names and their attributes for 
a file, use the Display File Field Description command (DSPFFD) against the file. 

To access a source member, define the source physical file in your program as an external file 
with a continuation spec that uses the RENAME keyword to rename the record format to 
something different than the file name. (The record format name in a source physical file is the 
same as the file name, which RPG will not accept.) 

This type of processing is well-suited for writing documentation systems, such as cross-reference 
programs. 
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by Kenneth Copenhaver 

Here is a simple method for adding flexibility to S/36 DFU LIST by allowing several commonly 
used printer options. I have added three parameters to the LIST procedure: 

P14: "H" assigns PRIORITY-O to the print file, putting it on hold in the print spool. Any other 
entry or no entry will assign PRIORITY-1. 

PI5: Specifies the number of copies to be printed. If no entry, the default is one copy. 

PI6: Specifies the forms number to be used. If no entry, it defaults to the standard forms 
specified in the #LIST procedure in #DFULIB. 

Four lines of code need to be added to the #LIST procedure in #DFULIB just above the 
PRINTER statement, and three parameters must be added to the PRINTER statement, as shown 
in Figure 1. 

The default forms number ('000 T is used in the example) should be set to the standard forms 
used in your shop. The three printer options can be used separately or in combination. Additional 
parameters could be added in the same manner to make use of any other PRINTER statement 
parameters 

Kenneth Copenhaver Burlington, Vermont 

Figure 1 Changes to PRINTER statement 

Change the PRINTER statement to: 

// PRINTER NAME-#DFPRINT,PRIORITY-714?,COPIES-?15?,FORMSNO-?16? 

Insert before the PRINTER Statement: 

// IF 7147/H EVALUATE P14=0 
// ELSE EVALUATE P14=l 
// IF 7157/ EVALUATE P15=l 
// IF 7167/ EVALUATE P16='0001' 
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by Doug Talley 

If you have a band printer attached to your AS/400, you'll want to issue the following command 
when you start doing a lot of printing: 

CHGPRTF FILE(*ALL) + RPLUNPRT(*YES '') 

This says that if unprintable characters occur, blanks will print instead. Otherwise, you will get 
errors when you try to print job logs and other system listings. Don't let anyone tell you that you 
have to buy a new print band. 

Doug Talley Grand Rapids, Minnesota 
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by Doug Talley 

When you are configuring a PC with a printer, use the ONLINE(*NO) parameter for the printer. 
Then the AS/400 doesn't try to communicate with your PC printer until you start emulation. 
Also, set the IPL parameters for the AS/400 so print writers DO NOT start after IPL. When you 
start emulation, it tells the AS/400 that the printer is now ready to go online and it will start the 
printer. This will prevent many error messages for PC printer sessions. 

If not starting your writers at IPL bothers you, create a "startup" procedure to start specific non- 
PC writers. 

Doug Talley Grand Rapids, Michigan 
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by Midrange Computing Staff 

Initially, all subsystems use QDSIGNON as their sign-on display file. You can easily modify its 
appearance, and each subsystem can have a different sign-on display file.The default display file 
for the AS/400 sign-on screen is stored in library QSYS under the name of QDSIGNON. The 
source code (DDS specs) for this file is stored in source physical file QDDSSRC in the QGPL 
library by the same name. 

Change the sign-on display by performing the following steps: 

1. Copy source member QDSIGNON from QDDSSRC in QGPL library to a new member with a 
different name. 

2. Make desired changes to the new member, remembering two things: First, the order in which 
the fields are declared must not be changed. Second, do not change the total size of the input or 
output buffers. 

3. Create the new sign-on display file with the CRTDSPF command, placing the file in library 
QSYS. 

4. Change the subsystem description (CHGSBSD) sign-on display parameter (SGNDSPF) to the 
new sign-on display file. 

5. Either end and restart the subsystem or wait until the next IPL to activate the new sign-on 
display. 

One additional note: There is a 128-byte hidden field that can be changed to an input/output 
buffer which could be made available to application programs when the interactive job is started. 
See page 2-11 of the Work Management Guide for more information. 
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by Midrange Computing Staff 

Annoyed with having to override the same command parameter defaults over and over again. A 
tip sent in by Doug Talley of Grand Rapids, Michigan made us aware of an invaluable command 
that will change all that. The command CHGCMDDFT will let you change the system defaults 
for any OS/400 command. For example, you could change the WRKSPLF command to default 
to your main printer, rather than *ALL. The command to do this would look like this: 

CHGCMDDFT CMD(WRKSPLF) + NEWDFT('SELECT(*CURRENT PI)') 

(^CURRENT is placed before PI since it is the first default parameter in the SELECT list.) 
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by Openbbs Contributor 

Selected from DataNetwork's electronic bulleting board 
From: Roger Pence To: Craig Pelkie 

Do you know how the $$TIMER function (used to time-out workstation programs—not for 
communications) is implemented on the AS/400? I think I remember seeing something written 
about it but can't find it. 

From: Craig Pelkie To: Roger Pence 

I'm in the same boat. I think I've seen something, but can't remember. I'll see if anything surfaces 
in my digging. 

From: Rich Loeber To: Craig Pelkie 

I believe I saw something in IBM's announcements this week that $$TIMER would function 
correctly under OS/400 release 2.0. 

From: Craig Pelkie To: Rich Loeber 

You're probably right about that. Another enhancement that I saw in the 2.0 announcement is 
that, finally, after ten years, there's going to be a REDPE (Read Previous Equal) opcode in RPG. 
I never understood why they didn't provide this along with READE. Apparently, REDPE was 
supported all along by CPF (OS/400), but only in other languages. Better late than never, I 
suppose. 

From: Lance Gillespie To: Roger Pence 

There is a way to time-out workstations on the AS/400, but not using $$TIMER. It works like 
this: 
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1) When you create your DDS specs for the workstation use the INVITE keyword at the file 
level. 

2) When you compile the workstation DDS specs, specify a number of seconds to wait on the 
WAITRCD (wait record) parameter. This can be changed later using CHGDSPF if you want. 

3) Specify a number of devices (1) on the file continuation spec for the workstation file in the 
RPG program using the NUM keyword on the K spec. 

4) Specify a file information data structure for the workstation file using the INFDS keyword on 
the K spec. 

5) On the I specs, define the file information data structure you specified for the file using the 
*STATUS keyword to define a field to contain the status code for the workstation. 

6) When you want to display the file, WRITE the format name and READ the file name. You 
may not use EXFMT. Use a error indicator on the READ (pos. 56-57). If the READ fails, check 
the status code for the file. If it is 1331, the display timed out. From there you can have the 
program do whatever you want. 

The details for this are on page 9-61 and 9-62 of the RPG/400 User's Guide. (SC09-1161-00). 
Aren't you glad you bought an AS/400? Don't you love life on the bleeding edge of technology? 
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Selected from DataNetwork's electronic bulleting board 
From: Corey Hudson To: All 

Can anyone tell me how to test for an active job in CL? On the S/36 it was simple: 

7/ IF ACTIVE-OTHERJOB MYJOB". 

I tried using the CHGJOB command but I got the same results whether or not the job was active. 
The CL program I used was CHGJOB (OTHERJOB) JOBQ(QBATCH) followed by a few 
MONMSG statements. Keep in mind that I do not know the job number of OTHERJOB, nor do I 
want to use Data Areas to alleviate the situation. I would appreciate any answers to my dilemma. 

From: Art Tostaine To: Corey Hudson 

In our startup CL we submit to batch a CL program to monitor our UPS. Sometimes, throughout 
the day we re-run the startup program to generate reports, etc. The way I found out if the job was 
running already was like this. 

(1) Create a Message Queue with the name OTHERJOBQ, or whatever, and have OTHERJOB 
allocate it when it starts with Exclusive use (ALCOBJ). (2) When you need to know IF ACTIVE, 
have the program also try to ALCOBJ. Then, you can monitor message CPF1002, that the 
Message Queue is not available. 

If you wanted to check IF ACTIVE on more than one CL program, you just have each one create 
a MSGQ. The method is similar to Data Areas, but you don't need to write data. You just need 
one statement in each program to Allocate. 
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by Openbbs Contributor 

Selected from DataNetwork's electronic bulleting board 
From: DataNetwork staff To: ALL 

The September issue of the "other" magazine has an article on page 41 which includes a six-page 
MI program that will change a source-file member type. The article states, "The only method 
IBM provides for changing source type is the SEU member list display, which requires an 
interactive session. To change source type within a user application, you must use an MI 
program to update the attribute directly." While you cannot change the type directly, IBM does 
provide a command that will allow you to get the type changed in two easy steps. 

The QUSRTOOL library (see DataNetwork's May issue article on the widely-unknown tools 
library included with each AS/400) has a command called ADDSRCMBR. It is similar to 
ADDPFM, except that it allows you to specify a source type. So, to "change" a source member 
type, just add an empty member of the type you want with ADDSRCMBR. Then, COPYF or 
CPYSRCF the contents of the current member to the new member. If required, you can then 
delete the old member and rename the new member. 
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by Openbbs Contributor 

Selected from DataNetwork's electronic bulleting board 
From: Richard Shaler To: All 

Has anyone converted an RPG II program to RPG/400 that uses the Error Reset key technique 
that was published in the October 85 issue of DataNetwork? 

From: Art Tostaine To: Richard Shaler 

I am not familiar with the technique you are describing, but if you define your screen DDS specs 
with an ERRMSG keyword and indicator, the DDS will automatically show a highlighted error 
message (either text or MSG#) and require the user to hit error reset. It works great, and it is easy 
to code. 
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by Mark Fleming 

RPG has come a long way since its humble beginnings as a Report Program Generator. Is what 
we now see its final form? Will there be a System/36 Release 5.2 or 6.0? What's in store for 
RPG/400? These are questions that only IBM can answer correctly. But let's have a little fun and 
explore the possibilities. 

System/36 RPGII 

There have not been any enhancements to RPGII since 1987. Most believe there will be no more. 

I have always concurred, but a recent development makes me wonder. In case you have not 
heard, IBM has announced the AS/Entry System/36 (see Industry Watch elsewhere in this issue). 
This is a souped-up 5363 with increased memory and DASD. Rumors are circulating that IBM 
will release a new version of RPG for this machine. The improvements in the software will be 
selected to better prepare a S/36 shop for their eventual migration to the AS/400. The two most 
important RPG/400 functions missing in RPG II are externally-described files and external 
program calls. These enhancements have been informally mentioned by IBMers recently. 

It is difficult to imagine IBM devoting their resources to enhance S/36 RPGII when they don't 
even write their own PTFs any more. But there is a scenario in which they can add the desired 
functions, without writing any new code. External files, external program calls, and other RPGII! 
functions already exist in two proven third-party software packages from Amalgamated Software 
of North America (ASNA) and BPS Information Services. IBM could very well enter into an 
agreement with either of these companies to incorporate their product into the AS/Entry S/36 
RPGII. 

How true are the rumors? We have no way of knowing, but the naming of the product seems to 
portend some additional bridges to the AS/400. Of course, it could very well be a gimmick to get 
new buyers to think that they are getting something more than a S/36. 

What about existing S/36 users? If a new release of RPG is packaged with the AS/Entry, will 
IBM also give it to other S/36 users? They wouldn't give it to users across the board because the 
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cost would be too high to spend on a machine they want to phase out. But, I could see them 
selling it as an add-on package to those who want it. Only time will tell. 

If the rumors do not turn into announcements soon, I suggest that every S/36 shop get a copy of 
ANSA's or BPS's product. For a very reasonable cost, you can get RPGIII functions on your S/36 
NOW. Every user of either system that I have ever talked to is a walking testimonial of the 
product. If I ran a S/36 production shop, I would not even wait for IBM I would buy one of these 
products today. 

System/38 RPGIII 

There are nowhere near the number of S/38s as there are S/36s. RPG on the S/38 is nearly 
identical to the RPG on the AS/400. IBM intends to convert all S/38 sites to the AS/400 in a very 
short time frame. 

Given these facts, there is no reason for IBM to enchance anything, particularly RPG, on the 
S/38. If you think IBM is dumping the S/36 fast... 

RPG/400 

S/36 RPG has a limited future because it runs on a computer with a very limited life span. But 
what of RPG on the AS/400? Although RPG/400 is vastly improved over RPGII, some AS/400 
programmers are beginning to express some dissatisfaction with this language, and are looking to 
other languages such as COBOL, PL/I, and C. 

The discontent stems from one problem. The columnar format that makes RPG so easy to learn 
and use is also its downfall. The rigid format is the cause of all its major shortcomings. As IBM 
midrange systems programmers become more accomplished, they realize the compelling need 
for structure in their programs. The columnar format of RPG will not allow for indentation, and 
therefore cancels out any hope for a visual structure. 

A close kin to the structure problem is RPG's cryptic nature. Other modem programming 
languages recognize that more English-like coding results in a more comprehensible program. 
RPG allows for only 6-characters cryptic field names. 

One of the biggest limitations is the ridiculous way that we have to code expressions. Whereas 
most languages let you code something like ((A+B)*C)/D, in RPG you must code a series of 
ADD, MULT, and DIV calc specs. This is not a method that provides a graphic understanding of 
the formula. The same can be said for non-numeric expressions such as character string 
concatenations. 

Rumor has it that IBM will make substantial improvements to RPG/400 (RPG IV?). Many 
enhancements are being researched, but how could even the simplest improvement of larger field 
names be included in the fixed-format of RPG? We hear there are two possibilities: One way is 
to expand the RPG specification from 80-columns to 120-columns. The other way is to change to 
free-format calc specs. 

Some of the improvements being considered by IBM do not require changes to the format. These 
are local variables, date operations (difference between dates, what date is x number of days 
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from now, etc.), and dynamically sized arrays. Other improvements like larger field names and 
multi-dimensional arrays will require at least an expanded specification statement. But the most 
important improvements would require a free-format calc spec. That is the only reasonable way 
to provide for indentation of structured groups, and free-form expressions. 

If they make a change, we hope that they will go the whole nine yards to a free-format calc spec. 
Figure 1 will give you an idea of what this could possibly look like, as compared to the current 
format. As you can see, the difference is like night and day. 

SAA RPG 

Now for the bad news SAA RPG. S/3X users screamed when they realized that the SAA 
announcement did not include RPG as an SAA language. IBM listened and has since placed 
RPG under the SAA umbrella. This is both good and bad for you. It's helpful that RPG will be 
portable to the other SAA platforms. But, the problem is that only a subset of the RPG in use 
today will be portable. 

Describing SAA RPG by listing what is not included is the easiest. SAA RPG does not include: 

- WORKSTN file support 

- External files, their operation codes, and DDS 

- 30 digit numeric fields (just given to us in RPG/400 2.0) 

- File Information Data Structure 

As you can see, for all practical purposes, SAA RPG is not usable. Fortunately, you don't have to 
use SAA RPG, unless you are porting your software without modification to another SAA 
environment. Non-SAA RPG is still here, is still the same, and will still be evolving. 

You will have to make your own decision as to how important full SAA compliance is to your 
shop. It will involve many other components besides RPG. For example, are you willing to throw 
out CF when REXX arrives? 


Summary 

What is in the future for RPG? I have given you some ideas, but that is all they are. Your guess 
in as good as mine. We can't say for sure, and IBM certainly won't tell us. We'll all just have to 
do what we usually do when dealing with IBM wait and see. 


Figure 1 Current vs Free format RPG 

Free-format RPG? 


A sample of current RPG 
C CODE 

C TOTAMT 

C TOTAMT 

C PCT1 

C 

C TOTAMT 

C PCT2 

C 
C 

What it might look like 
C IF CODE *EQ 'A' 


code: 

IFEQ 'A' 

IFGT 5000 

SUB 2000 WORK1 

MULT WORK1 COMM 

ELSE 

SUB 1000 WORK1 

MULT WORK1 COMM 

END 
END 

in "Free-format": 
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C IF TOTAMT *GT 5000 

C EVAL (TOTAMT-2000) *PCT1 TO COMM 

C ELSE 

C EVAL (TOTAMT-1000) *PCT2 TO COMM 

C END 

C END 
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by Craig Pelkie 

If you have been following this series, you now have a pretty good grasp of CL programming. 

You know what a CL program should look like, and more importantly, some of the stylistic 
issues of writing CL. You know how to use conditional and looping constructs, and how to deal 
with CL variables. You have also learned how to work with data base files. 

You are now at the point where you need to understand how to get data into and out of a CL 
program. We have looked at example programs where parameters are passed to the program, but 
there are other methods of getting parameters to a CL program that you need to be aware of. 

Prompts and Commands 

One of the more familiar methods of getting parameters into a CL program is a prompt screen. 

This is very similar to the System/36 technique of using the PROMPT OCL statement, and 
accomplishes the same thing. You can use prompt screens as menus, information displays, or 
when you need to get options. For a complete article on using prompt screens, see Prompting 
Within CL Programs, DataNetwork, April 1989.1 won't duplicate that article here, but I will 
point out that using a display file in CL is similar to using a data base file. That is, you have to 
declare the file, which in the case of a display file must be externally-defined. By declaring the 
file and compiling your program, the indicators and fields used in the display file become known 
to the program. You can then use CHGVAR commands to set the indicators on or off, and move 
values into the variables. You can also test for command or function keys (including the ENTER 
key), by defining those keys in the DDS for the display file. 

Another technique of using displays to get information into a CL program is to prompt for CL 
commands. The commands that you prompt can be either system-supplied or commands that you 
create. Although you won't have quite as much control over the appearance of the display and 
screen attributes, there are many options that you can use to control the prompted command. 

Refer again to the Prompting Within CL Programs article for a review of the options available. 

Passing Parameters the Right Way 
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There is really only one right way to pass parameters between programs. That is, be certain that 
the number of parameters passed is exactly equal to the number expected, and be certain that 
each parameter is declared with exactly the same attributes (type and length). I am always 
surprised at the amount of trouble that people have with this, since it is really a very simple 
concept, and very simple to check for correctness. One of the first places to look, if you are 
calling one program from another and having problems, is with the parameter list. Chances are 
pretty good that you will find something amiss there. 

If you have the CL Programmer's Guide (SC21-8077) handy, turn to page 3-9. There are three 
whole pages of parameter-passing errors explained there, all of which boil down to violations of 
the simple rule stated above. The reason why parameter-passing errors are so difficult is because 
the called program usually works, to a point. When you have to debug this type of error, your 
tendency will be to skip right past the parameters. Don't. Check those first, and fix them if 
necessary. 

The rules for passing and receiving parameters are very simple: you can pass up to 40 parameters 
to a program. The parameters can be different types: some character, others numeric or logical. 
Since the maximum length of a CL character variable can be 2000 characters, it looks like you 
can pass up to 80,000 bytes of parameters if you use the maximum. I can't think of any reason 
why you'd ever do this, though. 

When you call another program and pass parameters to it, the other program doesn't really care 
or need to know what you've called the parameter in the calling program. That is, you can call 
program B and pass it parameters PARM1, PARM2 and PARM3. B can receive those 
parameters into a parameter list with names INI, IN2 and IN3, for example. As long as the type 
and attributes of the parameters match, that's all that's required. On the other hand, you might 
find it easier to use the same field names in the calling and called program, but there's no need 
for concern if you can't. 

Using External Parameter Lists 

As you develop systems on the AS/400, you will probably begin to write general purpose 
programs. For example, if you are coding a customer search program, you will try to have just 
one customer search program in the system, and have other programs call that as needed. The 
advantages of this approach are pretty obvious, and it's a good goal to have. 

What is not so obvious is how to set up parameter lists for all of the possible programs that you 
might have. For example, when you first start the system, you might have an idea of ten or 
fifteen different parameters that will be needed for most of the programs. For example, for an 
order processing system, you will have customer number, invoice number, invoice date, and so 
on. 

So how do you code parameter lists for your programs, both CF and other HFF? You could code 
the list with parameters that are only required for that program. A disadvantage of this approach, 
though, is that you limit your ability to pass through one program to another. That is, program A 
might want to get to C, but has to use B first. 

Rather than try to figure out all of the possible combinations, you will probably find it simpler to 
create an external parameter list. In RPG terms, this would be an external data structure, which 
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you create by defining a physical file. After creating this physical file, you reference it in RPG as 
an external data structure. When you call a CL program, the data structure gets passed as a 
character string. You can use the SUBSTRING function of CL to pick out the parts that you need 
in CL, and pass the entire structure to the next program. 

For example, the code shown in Figure 1 is a simple system that lets you call a program from any 
other program. The common parameters that will be used are defined in the physical file 
PFPARM. This file will never contain data; it is defined just so that the RPG program can 
reference it. The RPG program uses the parameter list file in the external data structure 
statement. An external data structure is nothing more than a means of telling the compiler to get 
the data structure subfields from an external file definition. The name of the data structure in the 
program, PMLIST, is used as the ENTRY parameter in the RPG program, as shown in the 
PLIST/PARM statements. 

Why did I include the field length 256? Well, it is probable that the total length of the parameters 
in the physical file will be less than 256 bytes. However, I want to use this parameter list in the 
CL program also, and I want to be sure that I am using the same length for every reference to the 
parameter list. By setting the length at 256,1 can create the CL program with a definition of this 
parameter list at length 256. It doesn't matter that I'm not actually using all of those positions. If I 
have to add another parameter or two to the physical file later, I don't have to go back into the 
CL program and adjust the length, assuming that it stays at or less than 256.1 don't care if the 
actual parameter hst is 10, 31, 116, or 256 characters long. Anything up to 256 is covered just the 
way it is. Also, if every RPG program in this system uses the external data structure statement, 
the subfield, and the PLIST/PARM statements shown, then there will always be agreement 
amongst all of the usages. For my purposes, I would put the first four RPG statements into a 
/COPY module and put that into my RPG source, then forget about the whole thing from that 
point on. 

If you examine the rest of the RPG program and the CL program, you will find that nothing too 
complicated is happening. The RPG program either sets the next program to go to, or signals that 
the previous program should be called again, based upon indicators 01 or 12. You might be able 
to use the previous technique if you are thinking along the lines of SAA compliance. 

The CL program starts by calling RPGPGM1, and passing the parameter list. Upon returning 
from RPGPGM1, the CL program determines if the call previous request was made, and formats 
the next program to call if it was. If there is a next program to call, processing continues at 
LOOP, otherwise the CL program ends. 

It may not be obvious why you would use this type of construct, so I'll tell you a few of the 
reasons why I do this. First, and most importantly, I can have any program in a system call any 
other that is using the same parameter list. Each program can decide the next program to call, 
based upon functions within that program. By simply moving the next program to a parameter 
field and returning, the next program will be called. An advantage of this method is that the 
invocation stack remains rather shallow. That is, with this method, the stack is only two deep: the 
CL program and the program that it called. This is supposed to be advantageous, in terms of 
machine resources used, as opposed to programs calling each other endlessly. Another big 
advantage has to do with a program calling itself recursively, a situation that you will probably 
create at some point if you have programs calling each other haphazardly. That is, A calls B. B 

Next 


Home 


Previous 








doesn't RETRN, but tries to call A. This causes message RPG8888, 'A' called itself recursively. 

A final note about this technique. You probably noticed that the numeric definitions in the 
physical parameter file use signed numeric (unpacked) fields. The reason for doing this is to 
allow the CL program to extract and use these fields, if needed. If the fields had been left to 
default to packed, then you couldn't use them in the CL program. You could use the 
SUBSTRING function to extract the field positions, but all you'd have would be a bunch of 
hexadecimal gibberish. By leaving the numerics as whole numbers, so to speak, you can extract 
them and use them in the CL program. 

Little Corners to Hide In 

One of the more unusual AS/400 objects is the data area. In fact, OS/400 knows about three 
types of data areas: the local data area, the group data area, and created data areas. All three 
types are used to contain data, on either a temporary or permanent basis. 

Created data areas are the result of some willful act on your part. That is, there is a 
CRTDTAARA (Create Data Area) command that you use to bring it into existence. And that's 
about all there is to it. You don't need any source statements to create a data area; all you need is 
a name and a length. That is what the system creates for you: a character string with a name (or a 
single numeric or logical field, if you choose). You can put anything you want into the character 
string, with the CHGDTAARA (Change Data Area) command. The system does absolutely no 
data validation for or against you. 

What good is this thing, anyway? Usually, you will find data areas used in place of control files. 

Lor example, it's not uncommon to find a one record control file in most systems. In an 
accounting application, the control file might contain various fields, such as next check number, 
next customer number, and so on. You can create a data area and store the same type of 
information in it. It will be easy to add additional information to the data area, since you don't 
need to change any file source statements. In fact, if you create the data area initially with more 
space than you need, you will already have the space available. 

RPG uses the DELN, IN and OUT statements to work with data areas. In an RPG program, you 
will need a data structure to break out the fields, if there is more than one field in the data area, 
but you can use the external data structure technique shown earlier to do this. You will probably 
want to create the external data structure definition, since one of the big disadvantages of a data 
area is that the system only knows it as a character string (or numeric or logical) of whatever 
length you created. That's it. Unlike externally defined files, the system doesn't know or care 
what you're keeping in a data area, so it's up to you to create some documentation about it. 

Now, why would you use a data area rather than the one record control file? I must say that it's 
kind of a toss-up to me, and I usually choose both equally. Data areas are easier to create, change 
and view than files. On the other hand, they are not as visible as files, and you may find yourself 
overlooking them when you're trying to debug something. I don't know if there are any particular 
performance advantages to using a data area over the one-record control file. I would suspect 
there is some machine-level advantage, since a data area doesn't need an ODP and so on. I doubt 
that there is any perceptible advantage to one over the other in an application, though. 

One instance where I do see a possible advantage for data areas is in control requirements. Lor 
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example, I am investigating using data areas to keep track of who has locks on certain records. 
Traditionally, this might have been done by keeping a separate file of locks, or putting a code 
into each record in the file, signaling the lock. The problem has always been system crashes, 
necessitating some kind of recovery program to remove the record-lock flags. With the data area, 
you can simply delete and recreate the data area when the system is back up. Just a thought. 

An Old Friend 

Former S/36 programmers are probably quite happy to find our familiar Local Data Area is alive 
and well. It is available in native mode also, so you don't have to feel sheepish about continuing 
to use it, what with parameters and programs calling programs and other accouterments of 
modern programming. You will be happy to know that CL can also use the LDA, very similarly 
to the way OCL would use it. For example, to extract something from the LDA, you could use 
the RTVDTAARA (Retrieve Data Area) command shown in Figure 2. To change the LDA in 
CL, use the CHGDTAARA (Change Data Area) command as shown in Figure 3. 

There's not a lot more to say about the LDA, except that you also have to use a DEFN statement 
in RPG/400 to use it. Refer to the section on the DEFN opcode in the RPG manual for an 
example. 

When You Hang Out With A Group 

One of the features of OS/400 is group jobs. This goes beyond the S/36 concept of interrupting a 
program to run another one, or even the AS/400 capability of having a secondary job. A group 
job is a means of starting any number of other jobs from the active job. This is useful when you 
need to let people work in disparate systems; for example, people working in Order Entry might 
need to get into the Inventory system at some point. Group jobs are one way that the system lets 
you get at these separate functions, without having to design for that access when you create a 
function. 

The potential problem with a group job is that it is, in fact, a separate job. There's no easy way to 
pass parameters from a program in one job to a program in another, so the Group Data Area is 
provided to facilitate this type of passing. The Group Data Area is unique to your group job; you 
might think of it as each terminal having it's own Group Data Area. This is different from the 
LDA, which is unique to each job. So each job within the group would have it's own LDA, and 
access to the GDA. If you want to pass parameters amongst group jobs, the easiest way is to use 
the GDA. The GDA is a temporary object; once you end the group job or signoff, it's gone. So if 
you need to keep anything that was in it, you may have to move that data to a permanent data 
area or file. The GDA partakes of the same shortcomings as other data areas: it's just a character 
string, 512 bytes long, and it's up to you to decide and keep track of what goes where. 

Manipulating the GDA is just like the LDA examples in Figures 2 and 3, except that you replace 
*LDA with *GDA. 

Personally, I have not been a big fan of group jobs. I suppose they are useful in situations where 
you can't predict the interactions that you'll need with various systems. For example, if you add 
new systems on a regular basis, it might be easier to just add the system without trying to 
integrate with existing systems. Supposedly, there is a benefit to using many jobs in a group 
rather than having one big job. However, it seems to me that if there is a chance of the same files 
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being used, the advantage would be to use the same job and use shared ODPs, as described in 
last month's article. But take your pick. Group jobs, in a way, are a primitive form of windowing, 
in that you suspend one task to work with another, and you may find they can be used to an 
advantage in your shop. 

Feedback 

One of the big issues with interactive programs is feedback, or letting the user know what is 
happening in a timely fashion. You may have seen some examples of OS/400 feedback when 
you use a long running command. For example, CPYF (Copy File), RUNQRY (Run Query) and 
OPNQRYF (Open Query File) are commands that send messages, letting you know that 
something is happening. 

Why bother with feedback? Well, remember the times that you've sat there looking at the screen 
(possibly even a blank screen), wondering if anything is happening. Chances are the system was 
doing what you wanted. Without feedback, you may have interrupted a long-running process just 
to check on it. The interruption, of course, only worsens the situation, since it now takes that 
much longer to complete the function. So you know what it's like to sit and wait; imagine what 
it's like for the people using your systems, who are unlikely to have as solid a grasp as you of 
what the system is doing. 

The good news is, it's really pretty easy to code feedback into your programs. OS/400 provides a 
message type that you can format with any information that you want, and it will display that 
message at the very bottom of the display. The feedback message doesn't require any user 
response, so it's not at all intrusive. If you're concerned with possible overhead, consider the 
alternative, which includes possibly canceling the job, turning off the terminal, or calling the 
operator and running the WRKACTJOB (Work with Active Jobs) command. 

For an example of how to code a feedback message, see Figure 4. This is a little CL program that 
you can call from any other program; its only purpose is to display the message that you pass to 
it. The MSGID CPF9898 is a predefined OS/400 message that you can use. You are expected to 
give it the MSGDTA that you want displayed. The MSGDTA can be up to 512 characters long. 
Usually, you would pass 80 or less characters, so that the text will fit on the one line at the 
bottom of the display. 

Specifying TOPGMQ(*EXT) (to program queue external), tells OS/400 that you want the 
message to appear on the external message queue of the job. For an interactive job, that means to 
display the message at the terminal. The MSGTYPE(*STATUS) indicates a status message that 
tells OS/400 that you are not expecting a reply to this message. 

You don't have to use the predefined message CPF9898. You may want to create your own 
messages, and use those as status messages. You create messages by first creating a message file, 
which is a type of system object. Use the CRTMSGF (Create Message File) to create the 
message file (see Figure 5). For some reason, CRTMSGF has a SIZE parameter, which you 
should ignore. If you set a maximum size to the message file, the book says that you can't extend 
the message file, so you end up having to create a new message file with a bigger size. If you just 
follow the example, you'll have everything you need. 

You add your own messages to the message file with the ADDMSGD (Add Message 
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Description) command. If you look up this command, you will see that it has some rather 
complicated parameters. The complications are there to allow you to define your own 
substitution parameters. This lets you use the same message for many different circumstances, 
without hardcoding the message. 

You can get a printed listing of some or all of the messages in any message file (including the 
system message files) with the DSPMSGD command. In fact, if you are going to create 
messages using substitution parameters, you might want to print some of the system message 
definitions first and see how they do it. 

You can change a message (including system messages) with the CHGMSGD (Change Message 
Description) command. You should probably not change system messages, since you could 
really create a mess. If you want to display different text for a system message, you're better off 
monitoring for that message (or the message that sends the message you want to change), and 
using the EXEC option of the MONMSG to display your own version. 

Finally, you can remove a message with the RMVMSGD (Remove Message Description) 
command. 

Be sure to read all of chapters 7 and 8 in the CL Programmer's Guide, since there is quite a bit to 
know about messages. We've only taken a superficial look at messages here, but you can begin 
to use messages with the feedback idea in mind, and have happier users. 

Looking Back, Looking Ahead 

You have now been exposed to many ideas that you can use in CL programs. By now, some of 
the mystery of this mysterious language should be removed. CL programming is really a matter 
of Just Do It. You can do some pretty exotic things in CL, and where you need more options, you 
can prompt for a command or call a program, returning new values to the program. 

If you are coming from the S/34 or S/36, you may be starting to realize that CL goes far beyond 
a replacement for OCL. You have to look beyond the OCL functions so as not to limit yourself 
to the subset of CL that takes the place of OCL. 

One of the best ways to learn more about CL is to continually read the manuals. You shouldn't 
try to read for understanding, necessarily, but just read and browse so that you will pick up ideas 
and see where examples are. Incidentally, I don't think much of the example programs in the 
manuals, since they don't show any sense of style and are very difficult to follow. You will find 
much better examples of CL programs in the QUSRTOOLS library (although I don't think much 
of the RPG programs in that library, stylistically speaking). I suppose many people figure that if 
it works, that's good enough, and it's probably true that you won't get a raise for writing well- 
styled programs. What you will do, though, is make it easier for yourself and the next person that 
has to maintain your work. You will find yourself working more methodically if you adopt 
strong stylistic principles. 

In the concluding article of this series, we'll cover some of the useful commands that you'll use 
on a daily basis. These include object manipulation commands, CPYF (Copy File) and an 
example of creating a command to perform a programming utility function. 
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Figure 1 CL to call any program from another program 



CL to Call Any Program 

From Another Program 

File PFPARM 

- Parm list file definition 
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R PARM 


TEXT('Parm list file') 
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PMPREV 

1 

TEXT('Return to previous flag'! 

A 

PMNXPG 

10 

TEXT('Next program to call') 

A 

PMPVPG 

10 

TEXT('Previous program') 

A 

PMCSNO 

5S 

TEXT('Customer number') 

A 

PMORDN 

5S 

TEXT('Order number') 

A 

(various other parms) 


RPG program 

RPGPGM1 using 

external parm list: (not to scale) 

IPMLIST E DSDSPFPARM 


I 



1 256 @PLIST 

C 

*ENTRY 

PLIST 


C 


PARM 

PMLIST 

C* (various statements) 
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C 


MOVEL'RPGPGM1' 

PMPVPG 

c* 




C 

*IN01 

IFEQ '1' 


C 


MOVEL'RPGPGM2' 

PMNXPG 

C 


RETRN 


C 


END 


C* 




C 

*IN12 

IFEQ '1' 


C 


MOVEL'1' 

PMPREV 

C 


RETRN 


C 


END 


CL program < 

controlling program flow: 


CLCONTROL: 

PGM 




DCL VAR(SPMNXPG) TYPE(*CHAR) 

LEN(10 ) 


DCL VAR(SPMPARM) TYPE(*CHAR) 

LEN(256) 


CHGVAR VAR(&PMNXPG) VALUE('RPGPGM1') 

LOOP: CALL PGM(SPMNXPG) PARM(&PMPARM) 

IF COND(%SST(&PMPARM 1 1) *EQ '1 1 ) THEN(DO) 

CHGVAR VAR(%SST(&PMPARM 2 10) + 

VALUE (%SST(&PMPARM 12 10)) 

ENDDO 

CHGVAR VAR(&PMNXPG) VALUE(%SST(&PMPARM 2 10)) 

IF COND(&PMNXPG *NE ' ') THEN(GOTO CMDLBL(LOOP)) 

ENDPGM 

Figure 2 Extracting first 10 positions from LDA 

Extracting First 10 positions from LDA: 
DCL VAR(&PARM1) TYPE(*CHAR) LEN(10) 

RTVDTAARA DTAARA(*LDA (1 10)) RTNVAR(&PARM1) 

Figure 3 Changing first 10 positions in LDA 

CHGDTAARA DTAARA(*LDA (1 10)) VALUE(&PARM1) 

Figure 4 CL "feedback" message sender 

CL "Feedback" Message Sender 
CLMSG: PGM PARM(&PMTEXT) 

DCL VAR(&PMTEXT TYPE(*CHAR) LEN(80) 

SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) + 

MSGDTA(&PMTEXT) TOPGMQ(*EXT) MSGTYPE(*STATUS) 

ENDPGM 

Figure 5 CRTMSGF command 

Create Message File Command 
CRTMSGF MSGF(DATANETWORK/DNMSGF) + 

TEXT('Message file for DataNetwork') 
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Simplified Interface to AS/400-to-AS/400 Display Station Pass-Through and File Transfer 
Support 

AS/400 consultants, software vendors, and multi-site companies all have the need to 
communicate AS/400 to AS/400. You may need to send a new program version from your 
AS/400 to a client, receive a file from a remote site, or just sign on to a remote AS/400. You can 
very easily perform all these functions without purchasing any software or hardware besides the 
standard AS/400 setup. The base communications and modem that come with the AS/400 are all 
you will need. 

This article presents the command LINK400. It will allow you to easily perform two different 
communications functions File Transfer Support(FTS) and Display Station Pass-through 
(DSPT). FTS lets you send and receive database and source physical file members between two 
AS/400s. DSPT lets you sign on to a remote AS/400. 

Since both FTS and DSPT are provided by IBM, why do you need LINK400? Because, as with 
most communications functions, it is not the easiest thing in the world to set up. You can do it 
yourself if you have a free day to educate yourself, write some programs, and do some testing 
with a remote site. It's easier to use LINK400. 

Setting Up 

Key and compile the commands and programs shown in Figures 1, 2, 3, and 4. When you 
compile the commands, make sure that you reference the CL program of the same name in the 
Program to process command parameter. 

The LINK400 command runs on both the source and target systems, sets up a communications 
line, controller, and device with the name TEMPRMT. Both FST and DSPT use these. It also 
creates a virtual controller (VCTL) and virtual device (VDSP01), used only by DSPT. The 
UNLINK400 command is used on both the source and the target system to vary off and delete 
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the communications line, controllers, and devices. (Throughout this article the term Source 
system refers to the calling system, the term Target system refers to the called system. Source is 
synonymous with Local, and Target is synonymous with Remote.) 

Note: The local location name is hard coded to the name TEMPLCL and the remote location 
name is hard coded to TEMPRMT. You can change these references in the CL programs if you 
already have lines, controllers or devices configured with the same names on the source or target 
systems. 

Preparing the Target System 

Regardless of whether you will be transferring files to the target, from the target, or sign on to 
the target system, you must always initiate LINK400 on the target system first. Once you set up a 
target system with LINK400, you will not need to re-initiate it as a target unless you vary off the 
line, controllers, or devices, with or without UNLINK400, or re-IPL the system. 

If you do not wish to keep the line and controllers varied on at the remote site, run UNLINK400, 
specifying 'T' for target in the SYSTEM parameter. We recommend that you run UNLINK400 
after you are through with LINK400 to prevent any chance of someone linking to your system 
without your knowing. Also, if you switch from being the target system to the source, or vice- 
versa, you must run UNLINK400 before running LINK400 again. 

LINK400 On The Source System 

The first panel displayed by LINK400 requests if this is a source or target system. Enter a 'S' in 
the SYSTEM parameter. 

The second panel LINK400 asks two questions. It wants to know the function, FTS or DSPT, 
that you wish to perform, and the target system's phone number. If you selected DSPT, you will 
be presented with a sign-on screen from the target system after pressing enter. Once connected, a 
user on the target system can also sign on to your system by running STRPASTHR. Users from 
both systems can be signed on to their respective remotes simultaneously. 

If you chose FTS, a third panel requests the password that is associated with your user ID on the 
target system (you must have the same user ID and password on the target), and more 
information about the file member. Once entered, the member is transferred. 

Basically, LINK400 wants to know if you will send or receive, what you are tranferring, its 
library destination and name, if different, and if it should automatically replace an existing 
member, if one exists. Be forewarned that if you specified no automatic replacement, and a 
duplicate member is present, no message is displayed. This is a function of FTS that we could 
not control. 

Just as with the target system, if you do not wish to keep the line and controllers varied on the 
source system, run UNLINK400 specifying an 'S' in the SYSTEM parameter. We also 
recommend that you always run UNLINK400 on the source system when you are done with 
LINK400. 

Technical Explanation 
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Program LINK400 calls the IBM-supplied program QY2FTML to perform file transfer, or it 
executes the IBM command STRPASTHR for signing on to another system. QY2FTML and 
STRPASTHR both require that an SDLC line, an APPC controller, and an APPC device be 
created. Additionally, STRPASTHR needs to have a virtual controller and device configured on 
the target system. LINK400 configures the line, controllers, and devices for both FTS and DSPT 
every time you execute it. 

Notice that the virtual device in LINK400 is set to 5251 Model 0011. The virtual device, used by 
DSPT only, defines the workstation at the other end of the connection. That is, the device type in 
LINK400 on the target system should match the calling workstion. To avoid confusion, leave the 
device type as is. We have found that this setting will work for all workstation that we have 
tested so far. 

The benefit of setting up the precise workstation type is that all that workstation's special 
attributes will function. If this is a requirement, set up the device type in LINK400 to match the 
device on the opposite end of the connection. If only the source system will be running DSPT, 
then LINK400 on the target system should specify the source system's workstation type. If the 
callee begins DSPT with the caller, the device type on the source system's LINK400 must match 
the target's workstation type. 

As we said, this is a confusing subject. Do yourself a favor and leave the device type as 5251 
Model 0011 until you further understand the concepts. 

Enhancements 

As with all DataNetwork programs, LINK400 is short, simple, and to the point. There is no 
specific message monitoring included, so you may want to add some. Also, there is very little 
validity checking, so invalid data may cause abnormal termination. 

An obvious improvement you can make is allow the passing of multiple members. You can do 
this by defining a list for the file member parameter in the LINK400 command. Then you could 
set up a loop in the LINK400 CL program to call QY2FTML for each member in the list. If you 
are new to CL, you may find processing the list a bit tricky. An alternate method is to pass the 
list to an RPG program and call QY2LTML from there. (See the RPG sample program in 
Appendix D of Communications: Programmers Guide.) 

You could also add two additional parameters to allow virtual device type and model to be 
entered through the LINK400 command. 

Considerations 

If you have a communication line that is active and using station address 01, LINK400 will fail 
no more than one line can be active for a given port at the same time. Either vary the line off that 
is using the station address, or if you have another address to use, change the STNADR value in 
the CRTLINSDLC command and both CRTCTLAPPC commands of LINK400. 

If you ever experience abnormal termination of LINK400, you should run UNLINK400 to return 
to a normal state. If LINK400 still doesn't execute after this, check your communication lines, 
contollers and devices with the WRKCLGSTS command. 
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Figure 1 Sample LINK400 display 


LINK400 Link to another AS/400 

Type choices, press Enter. 

Source or Target System .... SYSTEM _ 

File Transfer or Pass-Through . FUNCTION _ 

Target Phone# . TGTPHONE _ 

Password for Remote AS/400 . . . PASSWORD 

Option: S=Send, R=Receive . . . OPTION 

From Library Name.FROMLIB _ 

From Database Name . FROMFILE _ 

From Member Name.FROMMBR _ 

Target Library (Dft FROMLIB) . . TOLIB 

Target File (Dft FROMFILE) . . . TOFILE 

Target File Mbr (Dft FROMMBR) . TOMBR 

Replace Member if Exists .... REPLACE _ 


F3=Exit F4=List F5=Refresh Fll=Choices F12=Previous 
F13=How to use this display 


Bottom 


Figure 2 LINK400 command definition 


SYSTEM: 

FUNCTION: 


CMD PROMPT('Link to another AS/400') 

PARM KWD(SYSTEM) TYPE(*CHAR) LEN(l) MIN(l) + 

VALUES('S' 'T') RSTD(*YES) + 

PROMPT('Source or Target System') 

PARM KWD(FUNCTION) TYPE(*CHAR) LEN(l) + 

VALUES('F' 'P') RSTD(*YES) + 

PROMPT('File Transfer or Pass-Through') + 
PMTCTL(SYSTEM) 

PARM KWD(TGTPHONE) TYPE(*CHAR) LEN(15) + 

PROMPT('Target Phone#') PMTCTL(SYSTEM) 

PARM KWD(PASSWORD) TYPE(*CHAR) LEN(10) + 

PROMPT('Password for Remote AS/400') + 

PMTCTL(FUNCTION) 

PARM KWD(OPTION) TYPE(*CHAR) LEN(1) RSTD(*YES) + 

VALUES('S' 'R') PROMPT('Option: S=Send, + 

R=Receive') PMTCTL(FUNCTION) 

PARM KWD(FROMLIB) TYPE(*CHAR) LEN(10) + 

PROMPT('From Library Name') PMTCTL(FUNCTION) 
PARM KWD(FROMFILE) TYPE(*CHAR) LEN(10) + 

PROMPT('From Database Name') PMTCTL(FUNCTION ) 
PARM KWD(FROMMBR) TYPE(*CHAR) LEN(10) + 

PROMPT('From Member Name') PMTCTL(FUNCTION) 
PARM KWD(TOLIB) TYPE(*CHAR) LEN(10) PROMPT('Target + 

Library (Dft FROMLIB)') PMTCTL(FUNCTION) 

PARM KWD(TOFILE) TYPE(*CHAR) LEN(10) + 

PROMPT('Target File (Dft FROMFILE)') + 

PMTCTL(FUNCTION) 

PARM KWD(TOMBR) TYPE(*CHAR) LEN (10) + 

PROMPT('Target File Mbr (Dft FROMMBR)') + 
PMTCTL(FUNCTION) 

PARM KWD(REPLACE) TYPE(*CHAR) LEN (1) RSTD(*YES) + 

VALUES('Y' 'N') PROMPT('Replace Member if + 

Exists') PMTCTL(FUNCTION) 

PMTCTL CTL(SYSTEM) COND((*EQ S)) NBRTRUE(*EQ 1) 

PMTCTL CTL(FUNCTION) COND((*EQ F)) NBRTRUE(*EQ 1) 


Figure 3 LINK400 CL program 

LINK400: + 
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PGM PARM(&SYSTEM &FUNCTION &RMTPHONE &PASSWORD &OPTION &FROMLIB + 
&FROMFILE &FROMMBR &TOLIB &TOFILE &TOMBR &REPLACE) 


DCL 

VAR(&SYSTEM) 

TYPE 

(*CHAR) 

LEN(1) 

DCL 

VAR(&FUNCTION) 

TYPE 

(*CHAR) 

LEN(1) 

DCL 

VAR(&OPTION) 

TYPE 

(*CHAR) 

LEN(1) 

DCL 

VAR(& FROMLIB) 

TYPE 

(*CHAR) 

LEN(10) 

DCL 

VAR(& FROMFILE) 

TYPE 

(*CHAR) 

LEN (10) 

DCL 

VAR(&FROMMBR) 

TYPE 

(*CHAR) 

LEN(10) 

DCL 

VAR(&TYPE) 

TYPE 

(*CHAR) 

LEN(6) 

DCL 

VAR(&TOLIB) 

TYPE 

(*CHAR) 

LEN(10) 

DCL 

VAR(&TOFILE) 

TYPE 

(*CHAR) 

LEN(10) 

DCL 

VAR(&TOMBR) 

TYPE 

(*CHAR) 

LEN(10) 

DCL 

VAR(& TODATE) 

TYPE 

(*CHAR) 

LEN(6) 

DCL 

VAR(&REPLACE) 

TYPE 

(*CHAR) 

LEN(1) 

DCL 

VAR(&RMTPHONE) 

TYPE 

(*CHAR) 

LEN(15) 

DCL 

VAR(&RMTLOCNAME) 

TYPE 

(*CHAR) 

LEN(8) 

DCL 

VAR(&PASSWORD) 

TYPE 

(*CHAR) 

LEN(10) 

DCL 

VAR(&RCODE) 

TYPE 

(*CHAR) 

LEN(2) 

DCL 

VAR(&MSGNUM) 

TYPE 

(*CHAR) 

LEN(8) 


MONMSG MSGID(CPF2600 CPF2700) 

CHGVAR VAR(&TODATE) VALUE(' ') 

CHGVAR VAR(&TYPE) VALUE(' ') 

IF COND(&TOMBR *EQ ' ') THEN(CHGVAR VAR(&TOMBR) VALUE(&FROMMBR)) 

/* Create source, line, controller, and device */ 

IF COND(&SYSTEM *EQ ’S') THEN(DO) 

CHGVAR VAR(&RMTLOCNAME) VALUE('TEMPRMT') 

CRTLINSDLC LIND(TEMPLCL) RSRCNAME(LINO11) ONLINE(*NO) + 

ROLE(*PRI) CNN(*SWTPP) EXCHID(05600001) LINESPEED(2400) + 
AUTODIAL(*YES) DIALCMD(*V25BIS) DUPLEX(*FULL) 

CRTCTLAPPC CTLD(TEMPLCL) LINKTYPE(*SDLC) ONLINE(*NO) + 

SWITCHED(*YES) APPN(*NO) SWTLINLST(TEMPLCL) MAXFRAME(521) + 
RMTNETID(*NONE) EXCHID(05600002) CNNNBR(&RMTPHONE) + 

ROLE(*SEC) STNADR(01) 

CRTDEVAPPC DEVD(TEMPLCL) RMTLOCNAME(TEMPRMT) ONLINE(*NO) + 
LCLLOCNAME(TEMPLCL) RMTNETID(*NONE) CTL(TEMPLCL) + 

MODE(BLANK) APPN(*NO) 

VRYCFG CFGOBJ(TEMPLCL) CFGTYPE(*LIN) STATUS(*ON) 

VRYCFG CFGOBJ(TEMPLCL) CFGTYPE(*CTL) STATUS(*ON) 

ENDDO 

/* Create target, line, controller, and device */ 

IF COND(&SYSTEM *EQ 1 T') THEN(DO) 

CHGVAR VAR(&RMTLOCNAME) VALUE('TEMPLCL') 

CRTLINSDLC LIND(TEMPRMT) RSRCNAME(LINO11) ONLINE(*NO) + 

ROLE(*SEC) CNN(*SWTPP) EXCHID(05600002) LINESPEED(2400) + 
AUTODIAL(*YES) DIALCMD(*V25BIS) DUPLEX(*FULL) STNADR(01) 
CRTCTLAPPC CTLD(TEMPRMT) LINKTYPE(*SDLC) ONLINE(*NO) + 

SWITCHED(*YES) APPN(*NO) SWTLINLST(TEMPRMT) MAXFRAME(521) + 
RMTNETID(*NONE) EXCHID(05600001) INLCNN(*ANS) ROLE(*PRI) + 
STNADR(01) 

CRTDEVAPPC DEVD(TEMPRMT) RMTLOCNAME(TEMPLCL) ONLINE(*NO) + 
LCLLOCNAME(TEMPRMT) RMTNETID(*NONE) CTL(TEMPRMT) + 

MODE(BLANK) APPN(*NO) 

VRYCFG CFGOBJ(TEMPRMT) CFGTYPE(*LIN) STATUS(*ON) 

VRYCFG CFGOBJ(TEMPRMT) CFGTYPE(*CTL) STATUS(*ON) 

ENDDO 

/* Create virtual controller and device */ 

CRTCTLVWS CTLD(VCTL) ONLINE(*NO) 

CRTDEVDSP DEVD(VDSP01) DEVCLS(*VRT) TYPE(5251) MODEL(0011) + 
ONLINE(*NO) CTL(VCTL) KBDTYPE(USB) 

VRYCFG CFGOBJ(VCTL) CFGTYPE(*CTL) STATUS(*ON) 

/* File transfer requested */ 

IF (&FUNCTION *EQ 'F') THEN(DO) 

CALL PGM(QY2FTML) PARM(&OPTION &FROMLIB &FROMFILE &FROMMBR + 
&TYPE &TOLIB &TOFILE &TOMBR &TODATE &REPLACE &RMTLOCNAME + 
&PASSWORD &RCODE &MSGNUM) 

ENDDO 

/* Pass-Through requested */ 

IF ((&FUNCTION *EQ 'P') *AND (&SYSTEM *EQ ’S')) THEN(DO) 

STRPASTHR RMTLOCNAME(&RMTLOCNAME) VRTCTL(VCTL) 

ENDDO 

ENDPGM 

Figure 4 UNLINK400 command definition 

CMD PROMPT('UnLink AS/400 to AS/400') 
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Figure 5 UNLINK400 CL program 

UNLINK400: + 

PGM 

MONMSG MSGID(CPF2600 CPF2100) 

VRYCFG CFGOBJ(TEMPLCL) CFGTYPE(*CTL) STATUS(*OFF) 
VRYCFG CFGOBJ(TEMPLCL) CFGTYPE(*LIN) STATUS(*OFF) 
VRYCFG CFGOBJ(TEMPRMT) CFGTYPE(*CTL) STATUS(*OFF) 
VRYCFG CFGOBJ(TEMPRMT) CFGTYPE(*LIN) STATUS(*OFF) 
VRYCFG CFGOBJ(VCTL) CFGTYPE(*CTL) STATUS(*OFF) 
DLTDEVD DEVD(TEMPLCL) 

DLTCTLD CTLD(TEMPLCL) 

DLTLIND LIND(TEMPLCL) 

DLTDEVD DEVD(TEMPRMT) 

DLTCTLD CTLD(TEMPRMT) 

DLTLIND LIND(TEMPRMT) 

DLTDEVD DEVD(VDSP01) 

DLTCTLD CTLD(VCTL) 

ENDPGM 
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If you are designing or recoding a system that has many interactive programs, and many of the 
programs call each other, you should check to see if you can use the shared ODP for the 
WORKSTN (in RPG terms). The advantage of using the shared ODP is that every called 
program will initiate faster, since they are able to make use of the ODP created by the first 
program in the series. To do this, though, you have to include all of the record formats used in 
the different programs in the same display file. 

This is probably a foreign concept to many programmers, since the usual technique seems to be 
coding a separate display file for each program. But apart from the shared ODP advantage, you 
can also reuse formats in different programs, rather than having duplicate formats in different 
files. I know, most display formats are completely different and can't be reused in any event, but 
you might find that perhaps 10% of formats within an application can be reused, or made 
common. 

Now, the big disadvantage of this, and where I fear that most of you will turn your backs and 
walk away, is in the compiling of the RPG program. The problem is, if you have defined a 
display file with 40 different formats, all 40 of those will be compiled into the program. This, 
most assuredly, is not desirable. In fact, it can cause the compile to fail if you have used a field 
with the same name but different attributes in different formats. The solution to this problem is to 
use the IGNORE F-spec continuation, in which you tell the compiler, literally, to ignore the 
record formats that you name. Record formats that are not IGNOREd are included in the 
compile, so you get the same effect as compiling with a display file that includes only the 
formats that you want. 

I am the first to admit that this is not a good situation. In fact, I have passed along a suggestion to 
IBM that they offer an INCLUDE option also, since it seems to make more sense to me to tell 
the compiler what you want, not what you don't want. 

So why go through all this bother? I have found that the appearance of response time is 
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noticeably improved with the shared display file ODP. A project I'm working on includes about 
two dozen interactive programs. There is a difference in going from program to program with the 
shared ODP. Also, I tend to think that the fewer objects the better, so all of the formats are in one 
file, rather than 24 different display files. 

Like everything else about this machine, there are tradeoffs either way, but don't nix the idea 
until you've tried it. If you do decide to try it, you can specify the SHARE(*YES) parameter on 
the CRTDSPF (Create Display File) or the OVRDSPF (Override Display File) command. I've 
never encountered any problems with this SHARE option, such as you might have with data¬ 
base shared ODPs. I suppose there are some problems that can be caused, but I tend to write 
simple programs and haven't had the more obscure problems. 

Craig Pelkie San Mateo, California 
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When a program issues a READ as the first database file input operation, does it always get the 
first record of the file? Not necessarilly. If this program is sharing an Open Data Path with a 
previous program within the same job, and the file remains open between the programs, it may 
not get the record it is expecting. The READ will retrieve the record after the last record read by 
the previous program. 

Here is an example: Program PROGA chains to FILEA, then calls PROGB, whose first input 
operation to FILEA is a READ. If FILEA is a shared file, PROGB s READ will access the 
record following the one last chained to in PROGA. Another example: A CL program explicitly 
opens FILEA as a shared file. It then calls PROGA, which sequentially reads the entire FILEA 
file. After PROGA ends, the CL program calls PROGB, which is also supposed to sequentially 
read the entire file with an iteration of READs. Because PROGA left the record pointer in the 
ODP at the end of the file, PROGB will begin reading at that point of course, retrieving no 
records. 

You see, when a file's ODP is shared, the system uses one copy of the ODP for all programs 
within a job that access the same file. Therefore, the record pointer will not be reset to the 
beginning of the file when each subsequent program is called. The point is that if you are going 
to share ODPs for a file, you must be sure that your programs always position the record pointer 
before performing the first read. In fact, this is a good idea for any program, using shared files or 
not. 

For information about Open Data Paths, see Programming: Database Guide (SC21-9659) and 
Programming: Data Management Guide (SC21-9658) 
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We just converted our S/36 to an AS/400 a few months ago and have started doing unattended 
backups. This works great most of the time, but every so often someone leaves a tube on or just 
feels they don't need to sign off for backups at 12:00 midnight. This causes the save to miss the 
files they are using and locks up some batch jobs run along with the backups. 

Thanks to CL we have corrected the problem and our unattended job is running super. I have 
condensed the program for submission, but you can easily modify it to send warning messages, 
bypass programs which should never be canceled, check other subsystems, etc. 

The first thing you need to do is create CANINTPF (Figure 1), the DDS for the WRKACTJOB 
output. Then create the program CANINTJOB (Figure 2). 

To begin CANINTJOB, submit it to batch with the following command: 

SBMJOB CMD(CALL CANINTJOB) 

The file CANINTPF is declared in your CL program, cleared, and then used to hold a copy of the 
WRKACTJOB spool file. The file's records are read until the QINTER subsystem is reached. All 
jobs in this subsystem are then canceled. Once another subsystem, or the end of file is reached, 
the program ends. 

This program will cancel all jobs in the QINTER subsystem. All interactive jobs but the system 
console will be canceled (it is assumed that the system console is not in the QINTER subsystem; 
it should be in QCTL). When testing this program, you can simply change the ENDJOB 
command to DSPJOB until you get the program debugged. 

Mark Hawkins Augusta, Georgia 

Figure 1 Physical file CANINTPF 

A R WAJFMT TEXT('WRKACTJOB OUTPUT') 

A WACTL 1A 
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Figure 2 CANINTJOB CL program 

CANINTJOB: + 

PGM 

DCL VAR(&QINTER) TYPE(*LGL) LEN(l) VALUE( 1 0') 

DCLF FILE(CANINTPF) 

DLTF FILE(CANINTPF) 

MONMSG MSGID(CPF0000) 

CRTPF FILE(CANINTPF) SRCFILE(*LIBL/QDDSSRC) OPTION(*NOLIST + 
*NOSECLVL *NOSRC) LVLCHK(*NO) AUT(*ALL) 

OVRPRTF FILE(QPDSPAJB) PRTTXT(*BLANK) HOLD(*YES) 

WRKACTJOB OUTPUT(*PRINT) 

CPYSPLF FILE(QPDSPAJB) TOFILE(*LIBL/CANINTPF) SPLNBR(*LAST) 
DLTSPLF FILE(QPDSPAJB) SPLNBR(*LAST) 

RDRECS: + 

RCVF 

MONMSG MSGID(CPF0864) EXEC(GOTO CMDLBL(EOJ)) 

IF COND(%SST(&WASBS 1 1) *NE ' ' *AND &QINTER) THEN(GOTO + 

CMDLBL(EOJ)) 

IF COND(*NOT &QINTER) THEN(DO) 

IF COND((&WASBS *CAT &WAJOB) *EQ 'QINTER') THEN(CHGVAR + 
VAR(&QINTER) VALUE('1')) 

GOTO CMDLBL(RDRECS) 

ENDDO 

ENDJOB JOB(&WAJOB#/&WAUSER/&WAJOB) 

MONMSG MSGID(CPF1362) 

MONMSG MSGID(CPF1321) 

GOTO CMDLBL(RDRECS) 

EOJ: + 

ENDPGM 
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If you went to the AS/400 from the System/36, you may not be aware that the SETLL RPG 
operation code is no longer identical. It still does the same basic task on the AS/400, but there is 
more functionality. Not only does the AS/400 RPG position a file at a record, based on the value 
in factor 1, but it also will tell you the result of that operation. 

Specifically, if an indicator is present in positions 54-55, it is set on when the search argument is 
greater than the highest key or relative record number in the file. If an indicator is present in 
positions 56-57, it is set on when an error occurs for the operation. And, most informatively, if 
an indicator is present in positions 58-59, it is set on when it finds a record whose key or relative 
record number is equal to the search argument. Figure 1 illustrates. 

One example where this can be useful is checking to see if there are any transactions for a 
particular master record. Assume that file MASTER'S key is ACCT and file TRANS's key is 
made up of ACCT and SEQ. Figure 2 shows the statement that will test if a particular MASTER 
record has ANY associated transactions. It is easier than the S/36 method of a SETLL, followed 
by a READ, and then a check to see if the ACCT fields from both files match. 

Another new function is that you can use the figurative constants of *LOVAL and *HIVAL as 
search arguments. 

While we are at it, there is a related operation code that is not found on the S/36. SETGT is 
similar to SETLL, except that it positions the file at the next record with a key or relative record 
number that is greater than what is in factor 1. An indicator in position 54-55 is turned on if no 
such record is found. An indicator in positions 56-57 is set on if an error occurs. 

A SETGT or SETLL with *HIVAL, followed by a READP, finally makes it convenient to get to 
the last record of a file. 
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Figure 1 RPG/400 SETLL resulting indicators 

RPG/400 SETLL Resulting Indicators 
C ACCT SETLLFILE 999850 HILOEQ 

C* 50 = a match found 

C* 99 = argument greater than highest key or RRN number 
C* 98 = an error occurred 

Figure 2 Checking TRANS for associated records 

Checking TRANS for Associated Records 
C* ACCT is from MASTER 

C ACCT SETLLTRANS 50-EQ 

C* 50 on means records found 
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AS/400 job logs do not log CL statements by default. You can change this by specifying 
LOGCLPGM (*YES) and LOG (3) or LOG (4) in the CHGJOBD or CRTJOBD commands. 
After the program is run, use F10 on the DSPJOBLOG display to view the CL statements and 
detailed messages. Note: Remember that job logs are lost at sign off. 
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If you will be sharing a file among programs of a job, you should consider keeping the file open 
between programs. This will eliminate the time it takes to re-open the file for each program. The 
OPNDBF command, with TYPE(*PERM) will open the file, and keep it open, until you 
explicitely close it with the CLOF command. You must also be sure to specify a high enough 
level of usage in the OPTION parameter of OPNDBF. For example, if one of your programs 
updates the file, you must open it as an update file. If you opened it as input, no program could 
update it. 

For further information, see pages 8-7 through 8-13 of Programming: Database Guide (SC21- 
9659), and pages 1-20 through 1-22 of Programming: Data Management Guide (SC21-9658). 

DataNetwork staff 
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Selected from DataNetwork's electronic bulletin board 
From: Donna Sprague To: All 

I am relatively new (9 months) to the S/38 and RPGIII, and I have some questions on logical 
files and screen editing versus code. First I was wondering if it is more efficient to use the 
select/omit feature in logical files, to get the exact set of records I need or bring the whole file to 
the program. We are installing a large Loan system and have a person here from Hong Kong that 
says the less logical files the better, because they slow the system down, as every time a physical 
file is updated, every logical file associated with it is updated at the same time. That is not how I 
thought it should work but I don't know. Also they delete and rebuild their logical files 
constantly. 

Second, they do not use DDS to check for anything, such as making sure an input field is 
numeric, instead they execute a subroutine within the program. I am in favor of keeping as much 
out of the program as possible, but if their way is better, I'll give in. Just a note, their loan system 
is incredibly slow; average response time is 30 seconds and we only have 5 users on it. I would 
appreciate any comments or hints as this whole environment is very different for me (mainly 
mainframes, COBOL, and IMS). I am however getting to like it a lot, RPGIII still has it's 
drawbacks, but what language doesn't? 

From: Craig Pelkie To: Donna Sprague 

If possible, you would use logical files with the select/omit defined within the logical file. IBM 
asserts that this is more efficient than doing select/omit processing within your program. 

However, if you end up creating additional logical files, simply for different select/omit 
conditions (but with the same key structure), then it would probably be more advantageous to 
define the one logical, and move select/omit into the program. 

As far as editing on the screen, do you mean that they are entering numeric fields into screen- 

Next 


Home 


Previous 










defined alpha fields? There's not much point in doing that, since CPF will do the type checking 
for you. No point in trying to work around the machine, if it's going to do the same thing for you. 
As far as poor response time, there are many reasons for this. Usually, on the S/38, the problem 
is that there is not enough memory allocated to the interactive subsystem, or there are too many 
jobs at a time on the system. Another good technique to really slow everything down is to run 
more than 2 batch jobs at a time. You have to take a look around at everything going on, then 
make improvements to the obvious things first. 

In my experience, it seems that you can have up to (about) 20 logicals over a physical, and not be 
able to tell the difference in response time. If there are literally hundreds of logicals, then you 
may have a problem there. Also, if the files are good sized (100,000+ records), and you are 
constantly recreating them, that will put a pretty good load on the machine. 

As far as programming, go with your common sense. If it takes a long-winded explanation as to 
why one technique is superior to another, just go with the simplest thing that will work, and let 
the machine take care of the nitty details. 

From: Donna Sprague To: Craig Pelkie 

Thanks for the response. The logical files I am talking about are relatively simple, it just seems 
easier to bring only active records into my program when I have numerous other complex editing 
functions going on. The most logical's we have on a physical right now is about 10, and that is 
rare. For instance, the select specs changed on a large program today, and I just had to recreate 
the lgl instead of changing and running a 20 min. recompile. I will try to be sensible in my use of 
them however. In answer to the field editing, they don't seem to use SDA very much. They came 
from a S/34 to S/36 to S/38 to AS/400, and I think they still do things the old way a lot. They 
didn't want us to use the validity functions in SDA because I haven't been able to find a way to 
highlight and reverse image the field in error. They have been a big help in explaining the S/38 
to us in general, and helping us understand the old code so we will be able to maintain it. 

I don't mean to sound like I know so much and they don't, because I am very aware that I have a 
lot to learn about this system, I just don't agree with doing something one way because that's the 
way it's always been done. Anyway that's my problem not yours. The response on our system is 
generally good except for this system. As you said there are probably several factors. It is a very 
large and complex system, most of the users are on Passthru from the S/36, and there is a lot of 
overhead in the system that we don't use. We are debating re-writing it to take advantage of the 
S/38 when the system is installed and working correctly - do you think that will buy us anything? 

From: Craig Pel ki e To: Donna Sprague 

OK, I thought maybe you were entering numeric values into alpha fields, then editing all that. 

But there's generally no problem in doing range editing in the program, and it does give you 
more control over the display. Assuming that you are able to optimize everything else, rewriting 
should give you some advantages. Don't worry too much about stuff like using *INxx instead of 
indicators, since that doesn't buy anything in terms of response time (style is another issue, and 
you should do things in good style, but keep that separate from response). Look more to how 
programs call each other, how files are opened and closed, how programs return, etc. If your 
users are getting 30 second response time using Passthru, there might not be too much you can 
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do to improve that within the programs. If your 30 second response time is local, you probably 
can improve that. 


Next 


Home 


Previous 









MIDRANGE 

COMPUTING 

HR PUBLICATIONS INC. 


BBS: AS/400 Print Direction 


November, 1989 

Copyright 1989, Midrange Computing 


by Openbbs Contributor 

Selected from DataNetwork's electronic bulletin board 
From: Art Tostaine To: Mark Tilker 

How can we let a user direct his print key requests to any printer he wants? I originally used the 
CHGPRTF, but that makes the printkey go to the same printer for all users. I then tried to write a 
CL program to OVRPRTF, but after the initial CL program ended, the Override was cancelled. 

All of these users are in the S/36 Environment, and some are in true native. By the way, the Print 
Control program advertised in the back of DataNetwork did not solve my problem, it just lets 
you assign a user to a printer, but the user cannot change their assigned printer without signing 
off first. Just wondering. 

From: Mark Tilker To: Art Tostaine 

What I do is allow the user to change the outq for his job: 

CHGJOB OUTQ(QPRINT2) 

The problem with this is that all print for that job will go to that outq, unless overridden by a 
program or printfile. This works out pretty neat, my users can select where all their reports, 
including their print screens, will print. For my batch jobs, before I submit the job to batch, I 
retrieve the outq for the job (RTVJOBA OUTQ(&OUTQ)) and then submit the job specifying 
this as the outq: 

SBMJOB JOB(XXXX) OUTQ(&OUTQ) 

Some explanation is needed to the users. They don't always understand outqs, but in the end it 
works out pretty good. 

I forgot one more thing. In order for reports to go to the outq specified for the job, the printfiles 
must have OUTQ(*JOB) specified for them: 
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CHGPRTF OUTQ(*JOB) 

Then anything printed for that spool file will be sent to the outq specified for the job. 

From: Art Tostaine To: Mark Tilker 

Thanks for your quick response. I have one question, will this work in the S/36 EE? In the S/36 
mode, you don't define printer files like you would in native mode. I am going to give it a try 
now, though. 

From: Mark Tilker To: Art Tostaine 

I do not know a lot about the S/36 EE, but I talked to a buddy that told me you need to change 
the user's SESSION PRINTER with the PRINT command. He told me that this should 
accomplish what you want. I hope these suggestions help you. 
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Selected from DataNetwork's electronic bulletin board 
From: James Fowler To: All 

I need help with a little pain in the #% !x problem I have with my AS/400. Whenever I do a 
listing of a procedure using the print option on the PDM menu I get a double spaced listing... no 
matter what I do (most of the time any way....occasionally it will give me a single spaced listing 
but I don't know why). I honestly believe that IBM must have bought a major interest in the 
paper industry when they came up with the AS/400.1 have never seen a computer put out so 
much information about everything it does (whether you want it or not). Anyway, if someone 
could help me out with this one I would appreciate it. I'm tired of digging through the manuals 
for the umpteenth time. 

From: Mark Tilker To: James Fowler 

Check the record length of your source physical file. I ran into this after bringing over S/36 code. 
After copying my source to a 92-byte long source physical file, my source printed just fine. Your 
source physical file is probably longer than 132 columns (esp. when you include statement 
numbers and dates). 
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Consistent and Flexible AS/400 and System/38 Programming Style 

Due to the ever growing success of IBM's AS/400, the career of a programmer with any single 
company may decrease from the current low of two years it has already reached. As 
programmers move from one company to another, they are often exposed to different styles of 
programming and design. This will be evident the next time the need arises for your company to 
hire a new analyst. You will not be employing simply one programmer, rather, you will be 
employing a programmer who may have a style based on all the other styles he or she has been 
exposed to over the years. Your company must take precautions to protect itself from this 
melting pot of style and methods, or run the risk of having application software that lacks the 
consistency and flexibility that must be present in today's changing world. 

The establishment of programming standards is essential for any organization. Standardization 
problems may not surface for some time, but they will definitely arise when you need to replace 
one of the programmers on your staff. If that programmer wrote in a personal style with no 
company guidelines, you may have a hard time understanding and therefore modifying the 
application. Even the smallest change could take days to complete. 

Since programming on the AS/400,1 have seen the need for certain standards and have 
developed a set of my own. If you are soon to be rewriting your application, this would be an 
excellent time to begin implementing a set of standards, whether they are mine or some variation 
of your own. Throughout this article, I will discuss methods that I have used successfully and 
feel will meet the needs of most organizations. These suggestions are designed for the AS/400 
and System/38. However, you can adapt the concepts to meet your own needs on the System/36, 
also. 

When you try implementing new programming standards, you may find hesitation or resistance 
among programmers. But with time and education they will begin to follow and realize the 
benefits. If you follow two simple rules this transition will go smoothly. 
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1. Do not just announce one day this is the new way to write programs and expect everyone to 
follow the new rules. 

2. Get the programmers involved in the development of the standards. 

When you develop a new system, talk to the users first. In this case the programmers are the 
actual users. Just as you would not develop an application system without involving the users, 
you should not create standards without feedback from your programming staff. 

Naming Conventions 

A naming convention is very useful in controlling and identifying files, programs, and fields. 

You can use it as a tool for getting company programmers thinking along the same lines. In my 
opinion, any naming convention that you use is better than none at all, and provides at least some 
control. 

The naming convention that I have developed is divided into three sections: programs, files 
(Physical, Logical, Display, and Printer), and field names. Refer to Figures 1 and 2 as we discuss 
each. 

Let's first take a look at files. The file name should identify the application to which it belongs, 
the type of file, and give some idea of the English language reference to the file.This is 
accomplished through the series of codes: AAxxxnt. 

AA is the application code. For example, PR=Payroll, GL=General Ledger, BL=Billing, and so 
on. 

xxx is a user defined code. Try to give a cryptic, yet somewhat phonetic representation of the 
file. For instance, use MST for master, TRN for transaction, and so on. 

n is only used if the file is a logical file. If a physical file has three associated logical files, each 
logical file would have a different value of n (1, 2, and 3). 

t stands for the file type. For example, P indicates a physical file, PT indicates a print file, V is a 
logical file, etc. 

Record formats are named the same as the file name, followed by the letter R. 

For subfiles, name the Control Record format CTFxxx and the Data Record format SUBxxx. 

Programs have a naming convention similar to file naming. I use the format AAfxxxt. 

AA is the application code, xxx is also a user-defined code, but in the case of programs, should 
be kept to numeric values. You could set up numeric ranges for different types of programs. You 
could use 001-099 for transaction entry and edit listings, 100-199 for posting and summary 
reporting, and so on. The t code indicates the type of language in which the program is written. 
Examples are C for CF, K for COBOF, and R for RPG. 

For a program name, you can insert a fourth code, f, after the application code to identify the 
function that it performs. I use 0 for a workstation file, 5 for an inquiry program, 9 for a report 
program, etc. 
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Field names also need to follow a set of definite rules. Name physical and logical file field names 
to AAxxxx. If you are coming from the S/36, this may sound different from what you are used 
to. More than likely, you have used a prefix that indicates the file to which the field belongs. 

This is not necessary if your files are fully normalized, since there should not be any redundant 
fields among the files. Some key fields will be redundant between files, but that is acceptable 
since they all will have the same attributes. 

The best way to define your physical and logical fields is to define them all in one master field 
reference file (DDS); this becomes your dictionary, so to speak. Fields in each physical and 
logical file DDS will reference (with REFFLD) the master definitions. 

I name workstation file field names #xxxxx; general purpose work fields WKxxxx; data structure 
field names DSxxxx; and subfile field names @xxxxx. 

Printer file field names do not carry their own special format. They are whatever field names 
contain the data that the program will output. For example, a file listing program would use the 
file's AAxxxx fields and perhaps some derived WKxxxx (like totals) fields in the printer file. 

I name Data Areas xxxDTA, and name their fields DTAxxx. The one last special item is the 
subfile cursor, which I name RECnnn. 

Generic Programming Techniques 

Once you have consistency among the naming of programs and files, it's time to improve 
consistency and flexibility within your programs. You can accomplish this through what I call 
"generic programming techniques." 

My definition of generic programming is to limit, or entirely eliminate, hard-coded definitions of 
constants, field length, error messages, and any other data that you may need to change over 
time. By following generic programming rules, you will develop more flexible and maintainable 
code, and a program that is more readable to those besides the original programmer. 

The first step in generic programming is to define all the characteristics (edit codes, text, ranges, 
values, column headings for QUERY, etc.) about a field in the physical file's DDS (preferably in 
the application's Field Reference File). By setting up the fields' characteristics in DDS, you avoid 
having to change multiple programs when a change is made to a field. For example, if a status 
code field has its valid range changed from 0-5 to 0-9, you will only need to change the range in 
the DDS. This is more time-efficient than changing every affected program. By the way, one 
attribute that should always be specified is TEXT. This description field will provide useful 
documentation within your compiled program listing. 

All fields defined in DDS whose attributes are based on those of another field should reference 
the other field, rather than redefining it; this includes fields used for totals. The way to reference 
a field in DDS is by using the field level keyword REFFFD. This keyword will define a field 
with all the characteristics of the reference field. 

In Figure 2-A, the field #xxxxx will be defined with all attributes of field AAxxxx from the 
physical file AAxxxP. Figure 2-B performs the same operation, except that the field will be 
either 20 positions longer (+20) or 20 shorter (-20). 
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This referencing function is also available from within your programs using the syntax required 
by each language. In RPG/400, the operation is composed of several parts: Factor one contains 
*FIKE, the operation code is DEFN, factor 2 contains the field name being referenced, and the 
result field contains the name of the field you are defining. (See Figure 3.) 

The RPG statement shown in Figure 3-A defines the result field with the exact attributes as the 
factor 2 field. This statement will save a considerable amount of time and reduce the probability 
of error if the factor 2 field is ever resized. Figure 3-B is exactly Figure 3-A, with the exception 
that WKxxxx will be n larger, where n is any number. This number is placed in the result field 
columns 49-52. A leading +/- will indicate whether to increase or decrease the field. 

Both field-referencing methods are useful for fields that will accumulate totals, ensuring that the 
total field will always be larger than the fields being accumulated. 

Any field that you must define without referencing another field should be defined in a first cycle 
routine, not at the time it is used and certainly not more than once. This will help to limit the 
amount of time spent locating and changing field size and attributes. 

Another way to increase program flexibility is to change the way you perform tests to a constant. 
You can place the value of the constant in a DESCRIPTIVE variable first, and then use the 
variable name for the test. This variable should contain only one series of possible constants and 
be defined in only one location within the program during first cycle processing. Figure 4 
illustrates. Tests can then be coded like those shown in Figure 5. 

Defining constants as variables in your first cycle processing routine makes changing test 
arguments a breeze; only one line of code will require modifcation. 

This approach will also help make RPG a less cryptic language and provide a more English-like 
approach. 

Common items shared among programs such as report headings, tax tables, and month-ending 
dates should be defined in a single source for access by any program. You can use a control file 
or data area to hold the data. This will eliminate discrepancies among your programs (for 
example, XYZ Company, X.Y.Z. CO., and X Y Z Company). 

By using a simple maintenance program, you will be able to easily change these control fields 
and the entire application will instantly recognize the effect. You will not have to make any 
programming changes to the programs. 

Fikewise, error messages should be placed into message members for the same flexibility. This 
will help free programmers from doing tedious maintenance programming, allowing them to 
spend more time on program development and provide users with the desired flexibility. 

If the rules thus far are adopted, you will have programs which are more flexible and more easily 
understood and maintained than others. But we can carry this a step further by generically coding 
commonly-used routines. 

If you are going to code a routine, think of as many other possible places that could use that same 
function. Make a separate program out of this routine so any program can call it when needed. 


Next 


Home 


Previous 








These routine programs are called with the CALL operation code, passing the needed parameters 
to and from the program with the PARM statement. For example, you may have a routine that 
calculates the number of days between two dates. The calling program passes the two dates to 
the date routine program, which in turn passes back a field with the number of days. 

There are several benefits for writing code this way: 

1. The wheel only has to be discovered and tested once. 

2. Once tested and debugged, you have a set of functional code that any program can address. 

3. If the conditions for a routine change, you need only change the code in one location, 
eliminating further changes and compiles. 

Examples of routines which may be a candidate for this type of external program are: 

Date validation 

Date conversions (YMD MDY, Gregorian Julian, etc.) 

Alpha Searches 

Regularly used mathematical calculations 

Keep in mind, however, that if a sub-program is called on every cycle of the program, you'll be 
better off calling /COPY member subroutines. CALLs use significantly more overhead than 
EXSRs. 

Use the best language to handle the task at hand. On the AS/400, any program can call any other 
program with no regard to the language in which it is written. Keep in mind the task and user at 
hand, coding only what is needed to get the job done, but coding it in a manner that takes into 
account conditions that may not exist today. 

Documentation 

Documentation seems to be a troublesome area for programmers and is one that is never really 
completed. I try to provide the following as a minimum. 

1. A program title and a summary of the process being performed. 

2. A list of all indicators used and their primary functions. Try to limit the use of an indicator to 
one specific function. 

3. A list and summary of all subroutines used in a program. 

4. A list of all programs that are called. 

5. A section used to log all changes made to the program from one release to the next. Log any 
change made to a program with the date, description of the change, and the programmer's name. 
Do not delete, but rather asterisk-out changed statements. This will help if you have to reverse 
the change. Once you place a new release into production, the changes that were previously 
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made should be contained in the new release. You can remove the comments, as well as the old 
code, at this time. 

6. Place various comments in the program about the code. 

7. Label all nested END statements to help associate the top and the bottom of a structured 
group. 

These are the types of documentation that I like to see when I have to modify someone else's (or 
even my own!) program. If there is more, that is great; but any less is unacceptable. I have found 
that it takes only a little extra time to include this documentation. It is easier to spend a half hour 
or so when you are in the program, than to spend several days or weeks at a later date trying to 
decipher a program. It is very important that you get your staff in the habit of providing this 
essential documentation; it will save you time and money in the future. At the same time you will 
be forcing the programmer to develop a consistency among programs. 

Indicators 

Throughout the growth of RPG, the use of indicators has dropped considerably. It has gone from 
rampant and wild to a limited and more structured use. This decrease is due to structured coding 
(DO, CAS, IF) which has been able to replace some of the most common uses of indicators. You 
will always need indicators, but you can reduce their numbers and develop a consistency 
between programs. While setting up your standards for naming of file and programs, also set 
standards for indicators; this will prove very helpful later on. 

Though the CAB (compare and branch) opcode is a structured code, it should be avoided. It is 
simply a new name for GOTO, and GOTOs make for poorly structured programs. One of the 
rules for structured programming is that the program contains no GOTOs. 

Consistent Overall Design 

The design of a program should be consistent between programs, so each series of functions 
which are performed within that program are handled in the same manner every time. For 
example, a workstation program used for payroll data entry should contain the same 
characteristics as the one used for general ledger journal entries. 

Don't Forget the Users 

Consistency in an application is very important to the users, as well as to the programmers. Users 
rightfully expect consistency from program to program. Rules for the following should be 
established and followed: 

Command keys 

Action codes 

Screen layout & design 

The way data is presented on the screen 

Field sensitive help text 
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IBM has also seen the importance in this and has introduced System Application Architecture 
(SAA) as a guideline for user interfaces. I am not saying that you must follow IBM's SAA to the 
letter, or even at all. I am stressing that as analysts, we must find out the way that users would 
like to view data, and provide it through an interface that is consistent between programs and 
applications. 

Users will greatly benefit from these consistencies because they will only need to leam how to 
perform certain functions once, and will have confidence that these operations will be identical 
in all other programs. This will help to greatly decrease the learning curve for any new 
applications and help increase the over-all acceptance of a program. 

Do It Your Way, But Just Do It! 

By establishing a naming, design, and flow standard, you will be creating a situation that will 
make programming quicker and easier for your staff. This is because a programmer will only 
have to leam one style of code and know that it will be consistent between programs and 
applications, regardless of the original programmer. Any modifications that may be required to a 
program can be done with the least amount of effort and the maximum benefit. 

Not developing a series of company standards is inviting the development of poor programs. 
Though these programs might get the job done, they will lack the continuity that must exist. 
Whether you adopt some, all, or none of my ideas, it is still clear that something must be done or 
you will fall victim to your own creations. 
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Field Names and Special Purpose Names 
Code Object Type 

AAxxxx Physical/Logical file field name 

WKxxxx General purpose work field names 

#xxxxx Workstation file field names 

@xxxxx Subfile field names 

DSxxxx Data Structure field names 

xxxDTA Data Area name 

DTAxxx Data Area field names 

CTLnnn Subfile control record format 

SUBnnn Subfile data record format 

RECnnn Subfile Cursor Field 

Figure 2 Field referencing in DDS for workstation files 
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Figure 3 Field referencing in RPG 
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Figure 4 Descriptive definitions in one place 

Figure 4 

Descriptive Definitions in One Place 


C 

MOVE 

' 1 ' 

ON 

1 

C 

MOVE 

'O' 

OFF 

1 

c 

MOVE 

' Y' 

YES 

1 

c 

MOVE 

'N' 

NO 

1 

c 

Z-ADD 

.0751 

FICA 

44 
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by Craig Pelkie 

The last four articles in this series dealt with the coding of CL programs. This final article is a 
little different. We will get away from the coding, and instead, take a look at the subsets of 
OS/400 CL commands in which you must become proficient in order to feel in control of the 
machine. These subsets include object manipulation, the copyfile command, and the debug 
commands. Thanks to the (mostly) consistent design of OS/400, you will find it easy to learn and 
use these subsets. 

Objects, Objects Everywhere 

IBM has been describing "things" in the computer as objects since at least 1979, when the first 
S/38 manuals were available. The long and short of it is that everything in the machine, other 
than hardware, is a type of object. For example, a customer master file is an object type file, 
subtype physical file. Other file types include logical, printer, display and communications. 
Compiled RPG programs are object type program, subtype RPG. 

One of the advantages of this type of setup is that you can control objects with a small number of 
commands, rather than have different commands for each type of "thing." For example, think of 
two "things" on the S/36. One is a file, the other a program. For some reason, you find that you 
have to rename each of these. Renaming the file is easy, since you can use the RENAME 
procedure. The program is more complicated, since you need to do a LIBRLIBR procedure, 
followed by a REMOVE. 

OS/400, on the other hand, provides one rename command, RNMOBJ (Rename Object). You 
use a parameter of this command to specify the object type. In our example, we would specify an 
object type of *FILE and an object type of *PGM. 

This example, more than any other that I can think of, points out the fundamental difference of 
the AS/400 and the S/36. That is, on the AS/400, you need to spend quite a bit of time 
assimilating concepts before you go charging ahead. Most S/36 programmers will have quite a 
feeling of "lostness" when they first go native. For example, in the early days of the S/38, it was 
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amusing to me to see S/3 and S/34 programmers when they first started with the machine. 
Invariably, the first question was "where's the VTOC?" Upon realizing that there wasn't one, the 
first programming project was, of course, a VTOC. In retrospect, it wasn't such a bad idea to see 
everybody recreate the VTOC, since that got them into the swing of things pretty quickly. With 
the AS/400 you are more pampered, since you can always go over to the S/36 environment and 
grab the security blanket. 

Other "First Things" 

Another bit of charging ahead that troubles me is the tendency to adopt iron-clad standards 
without realizing the implications. For example, there are probably as many naming conventions 
as there are programmers. I would estimate that fewer than one out of ten newcomers to OS/400 
understand the powerful generic naming facilities available with the commands. This is too bad, 
because establishing poor standards at the outset makes it difficult to use the machine to its full 
potential. 

So how should you behave, if you are new to the AS/400? From my observation, if all your 
experience is with S/36 machines, and you have no S/38 experience, you should plan to 
eventually scrap and redo everything that you will do in the first six to eight months. The 
implication here is that you shouldn't be trying to rush through new projects when you first get 
the machine. Do some of the less complicated things. There's no way to tell you how you'll 
know, but you will definitely know "when the lights are turned on." 

Techie Talkie 

Whew! Now that I've prepped you with some of the burning issues, we can get on to this month's 
technical features. The first subset of CL commands is the subset that deals with information, 
manipulation, and control. One of the most maddening aspects of objects is that it's easy to lose 
track of where they came from. On the S/36 this was not such a problem. A file most likely came 
from the BLDFILE procedure or was created by a program. A source program was (usually) in 
the same library as the compiled version. And that pretty much took care of the things that you 
had to worry about on the S/36. 

On the AS/400, you can do a DSPLIB (Display Library) command to look at everything in a 
library, and not have a clue as to where any of those things came from. There are two commands 
that you can use to fill in the details, the WRKOBJ (Work with Object) and DSPOBJD (Display 
Object Description). Each command has advantages and disadvantages. 

If you want to work with one or more objects in a list format, and have the option of performing 
several different operations, use the WRKOBJ command. This presents a screen with options 
such as displaying and changing authorities, deleting, renaming, and displaying some additional 
description of the object. Now remember, programs are objects, files are objects, and everything 
else in this machine that you can create and have control over is an object, so you only have to 
become familiar with this one command to perform all these functions. Not bad, eh? 

Option 8 of the WRKOBJ screen, "Display Description," contains what may be important 
information to you someday. Specifically, it indicates the last date, time, and save medium that 
was used to save the object. You can think through this yourself, and imagine why this might be 
useful to you. However, one of the other important pieces of information that you will frequently 
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want to know is not available with the WRKOBJ command. That is why you also must become 
familiar with the DSPOBJD (Display Object Description) command. This command is from the 
S/38, so it's not quite as friendly as the more polished WRKOBJ, but I'll take the information 
however I can get it. The information I want that DSPOBJD provides is the source file, library, 
and member used to create the object, which is used for all the programs and files that you create 
in native mode. The DSPOBJD command is illustrated in Figure 1. The relevant parameter here 
is DETAIL(*SERVICE), which tells OS/400 that you want to see the source information. 
DSPOBJD is one of the "nice" DSP type commands, in that it provides you the option of creating 
an output file of the information. You might be able to use this information (the name of the 
object and the source location) to create things like "mass recompile" programs. 

The problem you will see, eventually, with the * SERVICE information is that it might point you 
to a dead-end. For example, if the source for a program was created in a temporary source file, 
and the program was created from that temporary source, then the *SERVICE information points 
you towards something that's no longer there. At that point, you have to go through your system 
and hope to find the source. I tell you this because there is almost nothing more disheartening 
than having to make changes to a program, and not being able to find the source. I also want to 
EMPHASIZE A POINT TO VENDORS THAT PROVIDE SOURCE CODE: for the sake of 
client relations, please make sure that the compiled objects that you provide point towards a 
source file that you provide. If that's not possible, then a simple documented summary of "where 
to find it" would be nice. The point is, the system can provide the information, so meet it halfway 
so that it can help you. 

Changing Things Around 

The commands you need to know here are MOVOBJ (Move Object), CRTDUPOBJ (Create 
Duplicate Object), and RNMOBJ (Rename Object). MOVOBJ moves an object from one library 
to another. CRTDUPOBJ "copies" the object into another library; the original object remains in 
the "source" library. RNMOBJ assigns a new name to an object; it remains in the same library. 
There are some restrictions listed in the CL Reference, Volume 4, for the MOVOBJ. Obviously, 
you must have authority to move the object. Also, there are certain types of objects that can't be 
moved, such as libraries, user profiles and device descriptions. Those types of objects are 
considered to exist in library QSYS and must remain there. That is why you don't have to specify 
a library name when you create those types of objects. Some types of message queues can't be 
moved. Lastly, you can't move an object into a library that already contains an object of the same 
type and same name. (That's object type, not subtype. That means you can't have a CL program 
and RPG program of the exact same name in a library, since the "type" is *PGM.) 

You want to be aware of what happens when you move an object into QTEMP. To put it simply, 
it disappears when the job using QTEMP ends. In some cases, that is exactly what you want to 
happen. On the other hand, you can't move some types of objects into QTEMP, notably 
*OUTQs. For that matter, you can't create an OUTQ in QTEMP either. This is maddening, since 
there are times when I know that I don't want the printouts, and in fact, want them to disappear at 
end of the job. IBM allows mainframe programmers to "dummy out" spooled output; I have no 
idea why they won't allow us to do it on the AS/400. 

In a CL program, you can control the MOVOBJ command by preceding it with the CHKOBJ 
(Check Object) command. CHKOBJ can tell you if an object exists and if you are authorized to 
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it. It tells you by issuing messages, which you monitor in your program. The list of messages that 
you have to monitor is in Appendix E of CL Reference, Volume 1. A typical MOVOBJ scenario 
might be to check first for authorization to the object that you want to move. This is also a check 
of that object's existence, since you will get a "not found" message if it's not there. You could 
then check your authorization to the "target" library, then check for the same object already 
existing in the "target" library. This probably sounds pretty involved, but it can be done as shown 
in Figure 2. 

You will want to become familiar with CHKOBJ, since you can use it in CL programs to "steer 
around" trouble spots (like things not being found and not being allowed to use them). The 
alternative, of course, is to deal with system-type messages reporting troubles to you. I guess 
nobody has third shift operators anymore, so if the trouble was in a batch job, you'll find the 
message when you come in the next morning. 

CRTDUPOBJ (Create Duplicate Object) is pretty useful, and does exactly what it says: create a 
duplicate. The nice part about this command is that you can create a duplicate in the same or a 
different library; if you create it in the same library, you will assign a new name. If you are 
copying a physical file, you can request that all data in the file be duplicated also. And yes, all 
members in the file are copied, so you don't have to worry about multiple member files. There 
are the usual types of restrictions and concerns with this command, which you'll find in the 
manual. You will usually use this command to copy programs and files from test to production 
libraries. Conversely, you can copy a production file into a test library so that you'll have some 
test data. You'll want to be careful if you are using a large multi-member file, though, since the 
CRTDUPOBJ will copy all the members. If you only need to copy one member for your tests, 
you might be better off with the CPYF command. 

Another handy command is RNMOBJ (Rename Object). This has the usual restrictions, one of 
which I'm sure is a problem for many installations: you can't rename line, device, or control unit 
descriptions. That's right, you have to delete them and create them all over again. Another odd 
restriction, according to the book, is that "a PL/I program cannot be renamed after it has been 
created." (Well, is there any other time that it can be renamed?) Otherwise, the RNMOBJ is 
fairly trouble free, but of course, don't try to create a duplicate object name. Also, IBM says that 
"renaming a library can cause programming errors," so be aware of that. 

Another rename command, somewhat more specific, is the RNMM (Rename Member) 
command. You can use this to rename a member in either a physical or logical file. The manual 
gives a rather amusing example of changing lead into gold. (I hope the people who wrote the 
manual and created the AS/400 have as much fun as I do working with the AS/400, and I mean 
that.) 

I Want It All Now 

One of the commands that you might really need someday is the ALCOBJ (Allocate Object) 
command. With this command, you can check for the availability of an object before you try to 
use it. Usually, you will just want to see if the object is available. For example, for an object type 
*FILE, you can check for *SHRUPD (Shared for update) or *SHRRD (Shared for read). Other 
times, you need to ensure that nobody else is using the object; in that case, you can allocate it as 
*EXCL (Exclusive). Obviously, it makes no sense to over-allocate an object, since you will just 
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prevent other things from happening, but the capability is there when you need it. 

You can use DLCOBJ (Deallocate Object) to release a lock that you have on an object. For 
example, if you start a long batch job, you might need a restrictive type of allocation in the 
beginning. Later in the job, you don't need the restriction, so you can use DLCOBJ to release the 
restrictive lock that you put on with ALCOBJ. If you are going from a more restrictive to a less 
restrictive ALCOBJ, the manual indicates that you should perform the second (less restrictive) 
ALCOBJ, then perform the DLCOBJ to release the first (more restrictive) ALCOBJ. I don't 
know why they recommend the ALCOBJ/ALCOBJ/DLCOBJ sequence, rather than 
ALCOBJ/DLCOBJ/ALCOBJ. 

You can see an example of object locks at your terminal by entering the WRKJOB command, 
then selecting option 12, "Work With Locks." Just signing on creates about a dozen different 
locks, all system-type stuff. 

If you don't use ALCOBJ, an allocation is created when you use an object. Allocations not 
released with the DLCOBJ command are released at the end of the routing step. (This is different 
from the end of a job, but for your purposes, when the job ends, the routing step ends.) 

A Program Within Itself 

One of the more powerful commands in OS/400 is CPYF (Copy File). Indeed, you should take 
whatever amount of time you can to thoroughly investigate this command. The reason why I 
recommend this to you so highly is that you can use CPYF in many cases where you would 
otherwise have to write a "quickie" program. 

For example, it is not that uncommon on a database system to add another field to a file. 
Sometimes, you want to add the field in the middle of the record, since you may be trying to 
group fields within the record format. In the past, you would have to write a short program to 
copy the old file to the new, working around the new field. With CPYF, you can specify that 
OS/400 copy like-named fields (remember, your database files are externally defined, so the 
system knows where the fields are in each record). 

You can copy subsets of records. The subset can be based upon a "from" and "through" record 
number; I usually use this when I want to get a quick dump to the printer. For example, copy 
FROM record 201 TO record 250, printing a HEX dump. (I know, there are modern inquiry 
programs, but I seem to get a better feel for things when they're printed.) 

You can also copy from/to a specific key, or combination of keys. For example, if the key to the 
file is made up of four fields, you can specify a starting and ending key of from one to four 
fields. 

If you know that a character should be in a certain position in the record, you can copy based 
upon that character. This is similar to the S/36 COPYDATA, and this will be your only option 
for selection if the file is not externally defined. For externally defined files, you can name a 
field that you want selections based upon, for example, include if DEPT equals 419. 

All this might not sound so impressive, until you realize that CPYF allows you to use most of 
these selection options in any combination, with multiple selections allowed. For example, you 
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can specify up to 50 field selection tests. 


CPYF and its variants are used to copy data from one device to another. I've already mentioned 
copying to the printer. You can also copy to diskette and tape, or any combination thereof. If you 
will be doing a lot of device-oriented copying, you will need to become familiar with the 
commands specific to devices: CPYFRMDKT (Copy from Diskette), CPYFRMTAP (Copy from 
Tape), CPYTODKT (Copy to Diskette) and CPYTOTAP (Copy to Tape). These commands can 
be a bit tricky, and you will probably need to also use OVRDKTF (Override diskette file) and 
OVRTAPF (Override tape file) commands to specify all the parameters you need. You should 
try out these commands before you need them, because I guarantee it will take several attempts 
to get all the parameters right. At least it does for me, which proves that there is always more for 
me to leam about this machine. 

The Greatest Thing About The AS/400 

In a way, I've saved the best for last. Once you use this feature of the AS/400, you will never 
want to go back to programming the S/36. More than anything else about this system, this feature 
is responsible for the claims of (wildly) improved programmer productivity. 

What is the greatest thing about the AS/400, as far as a programmer is concerned? The greatest 
thing about the AS/400 is the built-in debugging features. You don't have to do anything special 
to prepare a program for debugging; just compile it in the usual fashion. Then get the most recent 
listing and prepare to run the program. When it misbehaves, you should locate the general area in 
your program where the problems are. Open your listing to that page, cancel the program, then 
get ready to do some productive work. 

You have to tell OS/400 that you intend to do some debugging. You do this by using the 
STRDBG (Start Debug) command. You can specify up to 10 programs that you want to debug, 
but if you're just starting, just use the one that you know is acting up. After you enter the 
STRDBG command, you can enter the ADDBKP (Add Breakpoint) command. The ADDBKP 
tells OS/400 that you want it to stop before executing a statement, and let you have a look at 
things. You tell it where to stop by giving it the statement number on your listing (for RPG 
programs, choose a statement that "does something," not a comment statement). The best part 
about ADDBKP is that you can specify up to 10 variables that you want displayed. No more 
guessing! No more print-dumps! These variables can be fields, indicators, or arrays. 

Now that you have one or more breakpoints set, start the program again. When it reaches one of 
the breakpoint statements, you will see a screen telling you at which breakpoint you are. If you 
gave it some variables to debug, you will see those also. You can use the ROLL or PAGE keys 
to see additional variables not shown on the first screen. 

But wait, there's more! (Kind of like the ginsu-knife of computers.) There you are, looking at 
your breakpoint display, and you see that indicator 50 is off when it should be on, or CUSTID is 
still at zero when it should be 10543. You can press F10 to go to the command entry display, and 
change the value of any variable or indicator used in the program, while the program is 
executing. You use the CHGPGMVAR (Change Program Variable) command to fix things up. 
After you make your change, press F12 to go back to the breakpoint display, then F12 to get it 
running again. 
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I still get goose bumps when I remember how we first learned about this in the prehistoric days 
of release 1.1 on the S/38. Nowadays, interactive debugging hardly raises a yawn from the jaded 
veterans, but you will certainly feel a sense of awe the first time you're able to wrestle an 
intransigent bug to the carpet. The reason why this is so valuable is that you can accomplish 
much more work in a shorter amount of time. You can probably hunt down many bugs 
simultaneously, rather than laboriously go through compile/test/debug sessions. By being able to 
get right into it and fix it while it's running, you can get more use out of a bug-hunting session. 

Now granted, it will take some practice to get the full use of this technique. For example, when 
you're first learning how to use the interactive debugger, you might have some questions as to 
where to place breakpoints. It does no good to place them at random, and no good to place them 
in sections where everything is working right. You'll have to think through the code first, and put 
them in strategic locations. If you use subroutines, putting them on the BEGSR/ENDSR 
statements might be useful. If you use GOTO/TAG, you could put it on the GOTO statement. Or 
at the start of loops. Sometimes, you will want to put in a breakpoint just to tell you that you got 
to a section of code; you don't need to specify any variables if you don't need to look at any. 

Also, you might have "instrumented" a program with a great number of breakpoints. As soon as 
you establish that things are OK in certain sections, you can use the RMVBKP (Remove 
Breakpoint) command to tell OS/400 to not stop there anymore. You can use RMVBKP when 
you are at a breakpoint by going to the command entry display (F10) and specifying which 
breakpoints to remove. 

There is another debugging option that you should investigate, which I truthfully have only used 
about three times in 10 years. That is the "trace" debugging feature. Essentially, you can tell 
OS/400 to "trace" the execution of your program; this information is put into a trace file which 
you then dump and examine. I simply haven't found this as useful as the interactive debugging, 
but you might want to investigate it. In any event, as soon as you get your hands on the CL 
Programmer's Guide, go straight to Chapter 11, "Testing," and start getting familiar with the 
functions that will change your programming life. 

Now It's Time To Say Good-bye... 

When I started this series, I intended on providing a "useful utility" program with this article. My 
idea was to provide a global search function, similar to S/36 POP. There is a command, 

SCNSRC (Scan Source) in the QUSRTOOL library that was to be the basis of this utility. Since 
the series started, though, Release 2 of OS/400 has been announced and started shipping. One of 
the new features included is a global search function, so it makes no sense to duplicate that here. 

I will say, though, that you should certainly install the QUSRTOOL library and create all the 
utilities in it, then take some time to become familiar with the tools. Many of them are quite 
clever, and perform functions that would be otherwise impossible or very difficult to do. 
DataNetwork will be saying a lot more about these tools in the future, so be sure to continue 
reading. 

I hope, if you are new to the AS/400, that you will have the time to leam about this machine. 
Apart from all other considerations, you simply must become proficient with CL if you are really 
going to be in control of the machine. Regardless of IBM's future directions, REXX, the RT, etc., 
if you have an AS/400 now or are soon getting one, then you will be dealing with CL. 
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You'll also have to "limber up your thinking" quite a bit, since things are done quite differently 
from the S/36.1 know that when you first start, you will have countless questions about how 
things are specifically done, and you will want an exact equivalent to what you now do. From 
my perspective, I can tell you that it will be easier for you once you begin to get a sense of the 
underlying concepts of OS/400.1 know that if you stick with it, you will eventually understand. 

Figure 1 DSPOBJD to get source information 

DSPOBJD to get source information 
DSPOBJD OBJ (DATANETWRK/LOSTOBJ) OBJTYPE(*FILE) DETAIL(*SERVICE) 

Figure 2 CHKOBJ before manipulating 

CHKOBJ before manipulating 

CHKOBJ OBJ(FROMLIB/MYFILE) OBJTYPE(*FILE) AUT(*OBJMGT) 

MONMSG MSGID(CPF0000) EXEC(GOTO CMDLBL(SKIP)) 

CHKOBJ OBJ(QSYS/TOLIB) OBJTYPE(*LIB) AUT(*OBJMGT) 

MONMSG MSGID(CPF0000) EXEC(GOTO CMDLBL(SKIP)) 

CHKOBJ OBJ(TOLIB/MYFILE) OBJTYPE(*FILE) 

MONMSG MSGID(CPF9801) EXEC(DO) 

MOVOBJ OBJ(FROMLIB/MYFILE) OBJTYPE(*FILE) TOLIB(TOLIB) 

ENDDO 

SKIP: (continue program) 
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It seems that we are all endowed with 20/20 hindsight. In looking back on software selections we 
have made, we get a very different and much clearer perception of what should have been. 
However, after acquiring all this new-found wisdom, we were still stuck with a software package 
that should not have been purchased. Our superiors, users, and certainly our own conscience will 
constantly remind us of this poor decision as we all live with it on a day-to-day basis. 

Having made some bad choices of my own, and inheriting some of others, I feel that I am in a 
position to offer some advice in selecting software. Hopefully, if these suggestions are carefully 
considered and adhered to, you can save many long hours of frustration in front of a CRT 
making patches and modifications. Poor software, even with all your fixes, never seems to 
accomplish the goal for which it was originally intended. 

Clues for Software That Should Be Avoided 

Poor Documentation: Be very cautious of a vendor who provides inadequate or poor quality 
literature, documentation, and demonstration materials. You will be safe in assuming that if these 
materials were hastily prepared and contain errors and typos, the software package will reflect 
the same level of effort. 

Source Code: Availability of source code is vitally important if your installation has a resident 
programmer, or someone with enough knowledge of programming to make minor changes. 

Many vendors will not provide source code for their programs. Others will provide source code 
for an additional charge. Be very careful of vendors who are overly protective of their source 
code. Without the source code, you are at the mercy of the vendor, and this is not a comfortable 
position in which to find yourself. 

Understandably, you can't expect the vendor to provide the source code for some types of 
packages, such as utility programs, 4GL systems, compilers, etc. These packages generally do 
not require modifications. I am speaking more along the line of application packages such as 
manufacturing, inventory, and accounting systems. 
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References: It is always a very good idea to ask the prospective vendor to provide you with 
names of people who are currently using the package you anticipate purchasing. If possible, ask 
them for references in your locality so you can visit a location where the software is in use. If 
this is not possible, then call two or three references and ask them how they feel about the 
package. Ask questions about ease of installation, how long the software has been in use, has 
telephone support and on-sight support been adequate, is the package living up to its promises, 
and would you buy from the vendor again? 

Who is marketing the software? In general, I feel it is much better to purchase software from the 
company which developed it. It is not too unusual to find software being marketed and installed 
by people representing companies other than the original developer. In many cases, these people 
are good at sales, but are not too well-versed in the mechanics of the software. They may or may 
not know what the strengths and weaknesses of a particular package are. Many times, you will 
find that the developing company and the marketing company will find it easier to pass the buck 
than seek a solution when a problem arises. 

The contract: Make sure that you incorporate your requirements and specifications into the 
wording of the purchase contract, so that there is no room for doubt as to what you expect the 
package to do for you. Watch for the wording of the vendor's disclaimers in the contract. 

Vendors sometime assume very little responsibility for the quality of the software. It would be a 
very good idea to have your company's attorney examine the contract carefully before it is 
executed. 

It's Worth the Time to Check 

In summary, I would suggest that you spend a little extra time in your search for the right vendor 
and the right package. Be a discriminating buyer and remember you are doing it in self-defense. 
For every good reputable vendor, there are several others vying for your dollar who will most 
certainly make your life difficult. 
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You've had a hard day, crunching code for the latest new AS/400 financial application that your 
controller needs yesterday. You deserve a break. How about logging on to your favorite BBS to 
play a couple games of Megawar — from your AS/400 terminal. 

From your AS/400?! That's right. Luckily for you, IBM ships all AS/400s with a 
communications line and a modem which is used for PTF downloading and Electronic Customer 
Support. You can also use these, along with the Interactive Terminal Facility (ITF) to call a BBS 
or any asynchronous (async) communications system. ITF will let your AS/400 communicate 
with the async world, just like any other async terminal can. 

Creating the Program 

Key the program CALLBBS from Figure 1 as a CL program (type CLP) in QCLSRC and create 
it with the CRTCLPGM command. 

The one variable that you will have to determine before compiling the program is the actual 
resource name of your machine. Plug this into the RSRCNAME keyword of the CRTLINASC 
command at the LINE tag. You can determine the resource name for your machine by using the 
WRKHDWPRD command and selecting option 1 (Work With Rack Configuration — 9406) or 
(Work with System Configuration — 9404). This will show you the communications adapter and 
the port resource names. You will have to know which line is attached to your modem. Our 
resource name is LIN011, but your's may be different. 

Setting the Modem 

The IBM 5853 modem is capable of 2400 baud communications, both synchronous or 
asynchronous. There is a switch on the front panel labeled 'A/S' which makes the modem async 
when in the "out" position. Don't worry about setting any of the rear panel switches; the defaults 
supplied by IBM will work fine with most PC communications software. The only switch which 
might be necessary to change is Switch 3, which controls the modem-to-modem flow control. If 
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on, the modem will send the XON (DC3 or ASCII 013hex or Control-S) or XOFF (DC1 or 
ASCII 01 lhex or Control-Q) characters. You'll know if you need the XON/XOFF protocol if you 
don't receive all the data, and the modem's ECL light blinks, or if the transmission "locks up" and 
you can't get it started again. If this happens, change the current setting of Switch 3 to the other 
setting. This will only affect the async setting, so don't worry about it affecting your 
communications with IBM in the synchronous mode. 

About the Program 

This program builds the necessary communications line/controller/device descriptions, varies 
them on, and then calls ITF. Once the session is finished, the program varies off the 
line/controller/device and deletes the descriptions. There is some error checking to insure that the 
descriptions are not still on the system, which if left unchecked, could cause the program to 
bomb. If the program finds the description, it deletes it and then rebuilds it again to insure that 
the proper parameters are used. If the terminal gets knocked off the line by accident (someone 
trips over the phone cord ...), the last MONMSG of the program will trap the abnormal 
termination and then vary off and delete the line/controller/device. 

Using CALLBBS and ITF 

To use the program, enter: 

CALL CALLBBS 

Once ITL begins, you can press LI 1 from the initial display to get the ITL telephone list. Initially 
there will be no entries on the list. Press LI3 to enter the BBS you want to call, and the dialing 
prefix "ATDT," which is the standard Hayes command for tone dialing. If you have a pulse dial 
phone you can enter "ATDP" to cause the phone to be pulse dialed. After you enter the phone 
number, press LI2 to come back into the dialing screen and then place a "1" next to the number 
you want to dial and press enter. You'll be brought back to the ITL TERMINAL screen and 
you'll see the command "ATDT phone number" on the screen. 

You'll also see the modem respond with "OK." If the BBS you're calling answers, you'll get a 
"CONNECT" message. If you've selected the proper number of DATA and STOP bits for that 
particular board (usually 8 bit, no parity, 1 stop), you'll get a connection. Once connected, you'll 
be able to use the standard command structure for the BBS. 

There are a couple of particular functions within the ITL facility itself. One is SEND 
PASSWORD (L10) which brings up another screen that allows you to type a password in a non¬ 
display password field. It's not necessary to use it since you can still type your password in at the 
normal ITL screen. 

Special Considerations 

If you are accustomed to using a PC to communicate with BBSs, you might have a hard time 
getting used to the fact that PCs utilize character-based transmission, versus the AS/400's screen- 
based transmission. The AS/400 Enter key appends a Carriage Return to the string you keyed. 
This presents a problem for some single-character options where the Carriage Return gets passed 
to the next command in line. There is a way around this problem. AS/400 ITL allows you to 
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"SEND DATA AS TYPED" by pressing F9. This will send the data without appending a 
carriage return. This should solve most of the problems you have. It is difficult to predict when 
you should use the enter key or use F9. You may notice that when you use the enter key, the 
command line or menu will re-display. If this happens, try F9. In general, I always use the enter 
key and then if I don't get the desired results, I use F9 instead. 

If you want to send a PC-type control character such as Control-C, press the ATTN key. You 
will be presented with a display that will allow you to key a single character A-Z or a numeric 1- 
9. The system will then send this character as if it had been preceded by the PC Control key. 

Since ITF doesn't give you a full 24 lines of display, you should configure your user profile on 
the BBS system that you are using to display 18 lines instead of 24. On the DataNetwork BBS 
this is easy: 

1) Go to the Utilities menu (U, Enter). 

2) Choose Reconfigure terminal (R,F9). 

3) Choose Set page pause (P,F9). 

4) Answer yes to the "Do you want a page pause" 

5) Specify 17 for the "how many lines per Display page" question (17, F9). 

Some BBS systems, such as DataNetwork BBS, perform automatic word-wrapping. Your 
AS/400 won't support word-wrapping. So, when you enter messages through ITF into a word¬ 
wrapping BBS, you will need to manually end your lines with the Enter key. 

When signing off the DataNetwork BBS, you should not issue the standard Goodbye (G) 
command. For some reason, you will get the QSYSOPR error message, "Line TERMLIN failed. 
Probable local hardware problem." To avoid this problem, press F3 to sign off instead. 

Receiving Files 

Unfortunately, while you can transfer data between machines using ITF, the transfer structure is 
set for fixed length records without any standard transmission protocol such as XMODEM. The 
data transfer function is in reality only a "screen capture" similar to those found on most PC 
communication packages. In order to "download" a file, you will be capturing the screen as the 
file is displayed to the screen. Since the file must be displayable to the screen, it must be in 
ASCII format on the BBS. This rules out the "archived" files found on most BBSs. The 
DataNetwork BBS stores their download files in ASCII specifically so ITF users can download 
files. 

To receive a data file, first create a physical file on the AS/400 to receive the data. If you are 
receiving a file that contains one or more source members, such as a DataNetwork BBS 
download file, create a source physical file instead. Do not create a source physical file, or the 
AS/400 will overwrite the first few bytes of your data with sequence numbers. Just before telling 
the BBS to begin the download, you will have to tell the AS/400 to select START 
SEND/RECEIVE (F5). The system will prompt you for the SEND or RECEIVE option and the 
type of file to receive. Select RECEIVE and FILE. Next, you'll be asked for the target 
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MEMBER, FILE, and LIBRARY. Once you've answered those prompts, you'll be asked whether 
you want to replace the old file, or append to the file, and whether you want to convert to source. 
You should convert to source if the file has a source member; if it is a data file with no source 
members, do not convert to source. 

After answering the AS/400 prompts, tell the BBS to download the file. Always select ASCII as 
the transfer protocol. 

From the point that you start RECEIVE, everything displayed to the screen will be captured in 
the file. This includes the download instructions you issue. Be sure to stop the file receive (F6) 
after the file has been transferred, otherwise the file will continue to capture everything displayed 
to the screen. Strip out any extraneous information in your target file. 

Problems 

If you have problems, first check your line status by using the command WRKLIND TERMLIN. 
If you select F14, you should see that the line is in the ACTIVE status. If you've got a 
CONNECT PENDING, it may be that the modem is in the SYNCHRONOUS status, or the line 
may not be connected to the modem. Make sure that you have the right resource name parameter 
for your machine. 

You can also check the status of the Controller by using the WRKCTLD TERMCTL command, 
and taking F14 to look at the controller and the device. If your line is not in an ACTIVE status, 
your controller and device will be in a VARY ON PENDING status, which means that they're 
waiting for the line to connect. 

Figure 1 CALLBBS CL program 

/* This program will create an ASYNC line, controller, and + 
device and vary them on. It then calls the interactive + 
terminal facility (ITF). When ITF is terminated, the program + 
will vary off the line and controller and delete all + 
descriptions that were created. */ 

CALLBBS: + 

PGM 

LINE: + 

CRTLINASC LIND(TERMLIN) RSRCNAME(LINO11) ONLINE(*NO) CNN(*SWTPP) + 

LINESPEED(2400) SWTCNN(*DIAL) AUTOANS(*NO) AUTODIAL(*YES) + 

DIALCMD(*OTHER) INACTTMR(*NOMAX) TEXT('Async line description') 

MONMSG MSGID(CPF2718) EXEC(DO) /* LINE EXISTS */ 

DLTLIND LIND(TERMLIN) 

MONMSG MSGID(CPF2633) EXEC(DO) /* LINE NOT VARIED OFF */ 

VRYCFG CFGOBJ(TERMLIN) CFGTYPE(*LIN) STATUS(*OFF) 

ENDDO 

GOTO CMDLBL(LINE) 

ENDDO 

CONTROL: + 

CRTCTLASC CTLD(TERMCTL) LINKTYPE(*ASYNC) ONLINE(*NO) + 

SWITCHED(*YES) SWTLINLST(TERMLIN) CNNNBR(1234) TEXT('Async + 
controller') 

MONMSG MSGID(CPF2716) EXEC(DO) /* CONTROLLER EXISTS */ 

DLTCTLD CTLD(TERMCTL) 

MONMSG MSGID(CPF2615) EXEC(DO) /* LINE NOT VARIED OFF */ 

VRYCFG CFGOBJ(TERMCTL) CFGTYPE(*CTL) STATUS(*OFF) 

ENDDO 

GOTO CMDLBL(CONTROL) 

ENDDO 
DEVICE: + 

CRTDEVASC DEVD(TERMDEV) RMTLOCNAME(BBS) ONLINE(*NO) CTL(TERMCTL) + 

TEXT('Async device description') 

MONMSG MSGID(CPF261A) EXEC(DO) 

DLTDEVD DEVD(TERMDEV) /* DEVICE EXISTS */ 
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GOTO CMDLBL(DEVICE) 

ENDDO 

VRYCFG CFGOBJ(TERMLIN) CFGTYPE(*LIN) STATUS(*ON) 

MONMSG MSGID(CPF2640) EXEC(DO) 

SNDPGMMSG MSGID(CPD0006) MSGF(QCPFMSG) MSGDTA(' Cannot vary + 
on line. Line may be in use. Aborting') MSGTYPE(*ESCAPE) 

GOTO CMDLBL(DONE) 

ENDDO 

VRYCFG CFGOBJ(TERMCTL) CFGTYPE(*CTL) STATUS(*ON) 

VRYCFG CFGOBJ(TERMDEV) CFGTYPE(*DEV) STATUS(*ON) 

STRITF RMTLOCNAME(BBS) 

MONMSG MSGID(CPF5138) EXEC(GOTO CMDLBL(REMOVE)) 

REMOVE: + 

VRYCFG CFGOBJ(TERMCTL) CFGTYPE(*CTL) STATUS(*OFF) 

VRYCFG CFGOBJ(TERMLIN) CFGTYPE(*LIN) STATUS(*OFF) 

DLTDEVD DEVD(TERMDEV) 

DLTCTLD CTLD(TERMCTL) 

DLTLIND LIND(TERMLIN) 

DONE: + 

ENDPGM 
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Reza Rafiee of Omaha, Nebraska submitted a utility, CLEANLIBS (see figure 1), that will 
"cleanup" all user libraries on an AS/400. By cleanup, we mean reorganize all files that have 
more than 10% of their records marked as deleted, remove observability from programs that 
have observability information, and optimize unoptimized programs. The benefits are improved 
performance and less wasted disk space. It is a perfect job to run during any idle period such as 
nights or weekends. 

We all know what file reorganization is, but what is observability and optimization? 
Observability is data required for online debugging that is automatically inserted into a program 
when you compile it. Unless you are still in the process of debugging the program, the 
observability information is just using precious disk space. Optimization deals mainly with 
register usage optimization, so a program would benefit in path lengths, and possibly instruction 
paging. There is an OPTIMIZE keyword on the compiler commands, but the default is set to 
*NO to save compile time (the compiler has to go through another phase to optimize the code). 
There is no negative side effect to optimization. CLEANLIBS will remove observability and 
optimize every program that needs it by use of the CHGPGM command. 

The reorganization takes place if the number of deleted records is greater than 10% of the entire 
file. You can easily change this to any number that you want. 

It is interesting how CLEANLIBS accesses information from the DSPOBJD output file. Each CL 
command that gives you the option of outputting to a file, also has a model file on the system 
which identifies the record format. This format contains a field name for each field in the output 
file. You can find the formats for these output files under "Writing the Output from a Command 
Directly to a Data Base File" in the Data Base Guide (SC21-9659). The model files cannot be 
used as the actual output file for the command. You must create your own file, and then override 
the model file with the name of your output file. You don't need to delete the file first, since the 
default for these CL commands is to replace the first member of a file. 
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The format for the DSPOBJD output file is QLIDOBJD in model file QADSPOBJ of library 
QSYS. The field name &ODOBNM is the object name of the objects listed (in this case libraries 
only). To find variable names of the model files, use the Display File Field Description 
(DSPFFD) command. The CLEANLIBS program checks &ODOBDM and omits system 
libraries (those starting with Q, #, $, %, and &) from being processed. You may want to omit 
development libraries and any other non-production type libraries. 

Another program, CLEANLIBSF (see figure 2), has to be created to perform the file 
reorganization. This is because a CL program only allows you to declare one file. CLEANLIBSF 
also uses the same technique as CLEANLIBS to obtain the information from the output file 
created by the DSPFD command. 

DataNetwork staff 

Figure 1 CLEANLIBS CL program 

CLEANLIBS: + 

PGM 

DCLF FILE(QADSPOBJ) 

MONMSG MSGID(CPF0000) 

DSPOBJD OBJ(QSYS/*ALL) OBJTYPE(*LIB) OUTPUT(*OUTFILE) + 

OUTFILE(QTEMP/LIBLIST) 

OVRDBF FILE(QADSPOBJ) TOFILE(LIBLIST) 

OPNDBF FILE(QTEMP/LIBLIST) OPTION(*INP) 

READ: + 

RCVF RCDFMT(QLIDOBJD) 

MONMSG MSGID(CPF0864) EXEC(GOTO CMDLBL(EOF)) 

IF COND(%SST(&ODOBNM 1 1) *EQ 'Q') THEN(GOTO CMDLBL(READ)) 

IF COND(%SST(&ODOBNM 1 1) *EQ '#') THEN(GOTO CMDLBL(READ)) 

IF COND(%SST(&ODOBNM 1 1) *EQ '$') THEN(GOTO CMDLBL(READ)) 

IF COND(%SST(&ODOBNM 1 1) *EQ '%') THEN(GOTO CMDLBL(READ)) 

IF COND(%SST(&ODOBNM 1 1) *EQ '&') THEN(GOTO CMDLBL(READ)) 

REORGF: + 

CALL PGM(REORGPF) PARM(&ODOBNM) 

RMVOBS: + 

CHGPGM PGM(&ODOBNM/*ALL) RMVOBS(*ALL) 

OPTIMIZE: + 

CHGPGM PGM(&ODOBNM/*ALL) OPTIMIZE(*YES) 

GOTO CMDLBL(READ) 

EOF: + 

CLOF OPNID(LIBLIST) 

ENDPGM 

Figure 2 CLEANLIBSF CL program 

CLEANLIBSF: + 

PGM PARM(&LIB) 

DCL VAR(&LIB) TYPE(*CHAR) LEN(IO) 

DCL VAR(&PERC) TYPE(*DEC) LEN(5 2) 

DCLF FILE(QAFDMBRL) 

MONMSG MSGID(CPF0000) 

DSPFD FILE(&LIB/*ALL) TYPE(*MBRLIST) OUTPUT(*OUTFILE) + 

FILEATR(*PF) OUTFILE(QTEMP/FILELIST) 

MONMSG MSGID(CPF0000) EXEC(GOTO CMDLBL(ENDPGM)) 

OVRDBF FILE(QAFDMBRL) TOFILE(FILELIST) 

OPNDBF FILE(QTEMP/FILELIST) OPTION(*INP) 

READ: + 

RCVF RCDFMT(QWHFDML) 

MONMSG MSGID(CPF0864) EXEC(GOTO CMDLBL(EOF)) 

CHGVAR VAR(&PERC) VALUE(000.00) 

IF COND(&MLNRCD *GT 0) THEN(DO) 

CHGVAR VAR(&PERC) VALUE(&MLNDTR / &MLNRCD) 

ENDDO 

IF COND(&PERC *EQ 00.10) THEN(DO) 

RGZPFM FILE(&LIB/&MLFILE) MBR(&MLNAME) 

ENDDO 

GOTO CMDLBL(READ) 

EOF: + 
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CLOF OPNID(FILELIST) 
ENDPGM: + 

ENDPGM 
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by Midrange Computing Staff 

A user in the Accounting department has quit and is being replaced. You must now set up a new 
user profile with the same characteristics and object authority as the previous user. Unless you 
are using group profiles, you might be in for more work than you bargained for. The AS/400 
provides a list of object authorizations by user that can be printed and used to grant authority for 
each object. However, this process could be very time consuming and tedious. 

The solution to this headache is to use group profiles. Group profiles are used to give the 
identical authority to each of a group of users. Instead of assigning the same objects over and 
over again to each user in a group, you can assign the objects to a group profile once, and then 
just assign the group profile to each user. 

There is nothing mysterious about a group profile. It is really just another user profile for which 
you will grant object authority once for a number of other user profiles which are logically 
grouped together. In our accounting department example, you would use Create User Profile 
(CRTUSRPRF) to create a "group" profile named something like GRPACCTNG. (We are using 
the GRP prefix to make identifying group profiles easier.) Use Grant Object Authority 
(GRTOBJAUT) to assign authority for all authorized objects to the group profile GRPACCTNG. 
Now, you can create the user profile for the new user, keying GRPACCTNG in the GRPPRF 
keyword. This will assign the object authority given to GRPACCTNG to the new user. Any new 
users can just as simply be added. If you want to add or delete an object for the entire group of 
accounting users, you only need to change the group profile with GRTOBJAUT or Revoke 
Object Authority (RVKOBJAUT). If a user is transferred to another department, just change his 
or her GRPPRF keyword. 

We suggest that even if you only have one user in a department, you always use group profiles. It 
might take you a couple extra minutes up front, but will offer more flexibility for the future. 
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There has been a lot of talk about SAA RPG lately. There is so much missing in the current 
specifications of SAA RPG, that it appears that it will be virtually unusable for any practical 
purpose. If you are unsure about what is not SAA-compatible in your own RPG programs, you 
can have the RPG compiler check for you. 

When the SAAFLAG keyword of the CRTRPGPGM command is set to *FLAG, the compiler 
will generate flags on the compile listing for any non-SAA code. For example, when we 
compiled a workstation program, we received the following three disconcerting messages: 

1) SAA RPG does not support device entry of WORKSTN 

2) SAA RPG does not support externally described file format for the device (DISK) 

3) File Information Data Structure format may differ in other SAA RPG environments. 

Not a pretty picture, is it? 

For more information on SAA RPG, consult the manual Common Programming Interface: RPG 
Reference (SC09-1286-0), which defines the SAA RPG language. 
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S/36 RPG programmers new to the AS/400 will be thrilled with the ablility to CALL other 
programs from a program. However, be careful to not get carried away. CALLs use significantly 
more overhead than EXSRing to a subroutine within the program. Unless the called program 
does a significant amount of work, or for some reason cannot be included in the program, 
consider using a subroutine and making it a /COPY member for inclusion into other programs. 
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Selected from DataNetwork's electronic bulletin board 
From: Mark Hawkins To: All 

I have an old S/36 application running in S36E. I want to write an RPG400 program which uses 
a S36E alternate index file. The index file has non-contiguous fields. RPG400 will not take 
EXTK for starting position. How can RPG400 read my S36EE alternate index? I would hate to 
have to use RPGII for any new programs. Any help will be appreciated. 

From: Art Tostaine To: Mark Hawkins 

You can use your S/36 alternate index very easily. Instead of coding EXTK for the key starting 
position, just put the FIRST position of the key. For example, if your key starts in position 2 with 
a length of 2, and 300 with a length of 5, just code a 7 for key length, and 2 for starting position. 

I went through the same thing when I converted my first program. Don't worry about RPG/400, 
it can only get easier.... 


Next 


Home 


Previous 











MIDRANGE 

COMPUTING 

HR PUBLICATIONS INC. 


BBS: AS/400 Disk Capacity 
December, 1989 

Copyright 1989, Midrange Computing 


by Openbbs Contributor 

Selected from DataNetwork's electronic bulletin board 
From: John Stauffer To: All 

We have an AS/400 B20 with two 315MB drives. Because of duplicate files, etc., during new 
program development we have gotten the "Serious Disk Capacity Error" message several times 
recently. The disk status show 86.5% at this time, and the PRTLIBANL from TAATOOLS 
shows only 403.7MB on the system (nowhere near 86% of 631MB). Which value is correct? 

Does the PRTLIBANL overlook certain objects? The local IBM office was not much help. I 
have also done a RCLSTG (reclaim storage), so there shouldn't be any wasted space. 

Lrom: Rich Loeber To: John Stauffer 

PRTLIBANL does not account for all system storage. Microcode storage and other system level 
storage is excluded. 

Lrom: Robert Munday To: John Stauffer 

You are suffering the same fate as my AS/400 client on a B30... NO DISK SPACE LOR 
ANYTHING! My client hovers around 85-90% full now as they have from just about day 1. It 
seems that IBM sold them just enough machine to get them to buy it, promising them that it 
would last them for YEARS. We all fail to take into account that the machine is delivered half 
full (in both our cases) which leaves little room for our applications. I'm sure IBM has suggested 
that you remove the source members from your machine to save space... they did to me... what 
dunderheads! You need more disk space. Period. 

Prom: Chris Rehm To: John Stauffer 

If you are doing a lot of program development, it may be that you can reclaim some space by 
eliminating the debug information from programs in active libraries. I develop in different 
libraries than I use for live programs, so I always run CHGPGM on programs in my live 
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libraries. You can run it on the whole library in one shot if you want. Another thing is to make 
sure that you are removing your QHST files as soon as they are full. Tape them if you need 
them. Debug stuff can take a bunch of space, up to 200k per program. Since your system only 
has about 300MB after the operating system, you need to squeeze every byte. Maybe you don't 
need to keep full sets of duplicate files on line? It will take longer, but if you are developing 
using a duplicate set of files, you can keep the ones you are not using offline. 
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Selected from DataNetwork's electronic bulletin board 
From: Bob Pearson To: All 

I would like to hear from anyone that has successfully used a 4224 printer to generate bar codes. 
Just starting out, and I am told it is possible but would like some detailed information. 

From: Rich Leober To: Bob Pearson 

We have been generating bar codes on two 4224s for about a year. We use IBM's IPDS software 
from an RPG program. The application is warehouse picking tickets. We put the invoice number 
and destination zip code on the ticket in bar code format. The posting machine in the warehouse 
reads the info with a laser gun and records outbound packages on diskette. The diskette is then 
cycled back through our system. It took about 1/2 day to dope out IPDS and another 1-2 days to 
make the necessary program changes. Except for the 4224's penchant for going through printer 
ribbons, the setup works just fine. 

From: Art Tostaine To: Rich Loeber 

We print Barcodes also with IPDS in RPG. Programming can be confusing at first, but once you 
get the hang, it's as easy as copying already working program lines to add another barcode. By 
the way, for anybody on the AS/400, external printer files work great with an IPDS printer, just 
use the keyword BARCODE, and forget about it. 

From: Nelda Rozek To: Art Tostaine 

Could you please tell me what manual to get to code bar codes or special characters of the 4224 
printer? I have the programming manual for the printer itself, but it doesn't relate to RPG. I can't 
seem to find anyone that knows which manual I should order. I would appreciate it very much as 
I have this new printer here that I can't get to work! 
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From: Art Tostaine To: Nelda Rozek 


If you have a S/36, you must order Program# PRPQ P84094 for a 5360/62, PRPQ P84095 (5799- 
CGL) for a 5364. The manual title is "Using the Intelligent Printer Data Stream Advanced 
Functions." The program costs about $500. If you have an AS/400, just use external printer files 
with the BARCODE keyword. P.S. for the 5360/62 unit, also use (5799-CGK) when ordering. 

From: Nelda Rozek To: Art Tostaine 
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